Про микрооптимизацию

Особо люблю разработчиков и разраборуководителей, у которых разработка доходит до точки “а сейчас надо тонко тюнить”, после чего ребятки вспоминают летучие фразы про оптимизации и сваливают в закат. Ваще не барское дело код шлифовать, проще машин подсыпать. Особенно если не платишь за них из своего кармана.
Тут такое дело.
Во-первых, действительно, не надо тонко тюнить код, если всё остальное в огне. Сначала надо сделать толково уровнями выше.
Во-вторых, действительно, не надо тонко тюнить код, если есть очевидные косяки вроде вытаскивания одним запросом всей базы ради одной записи.
В-третьих, следует помнить, что большинство умных и красивых фраз про оптимизацию говорилось в иных реалиях иных времён. А именно тогда, когда код, что обрабатывал миллион объектов в N секунд, писался не теми, для кого говорили красивые фразы. Вот как ребёнку запрещают в розетку вообще что-либо засовывать, а взрослый даже отвёрткой тыкает, так и в разработке все эти красивости от седовласых мужей не для всего контингента. Лишь бы джуниор проникся. А такой же седовласый сеньор, например, так и будет использовать goto там, где считает нужным.
Наше время — время тех, для кого “миллион” является обыденностью. Миллион запросов. Миллион строк. Миллион объектов. Потому микрооптимизация едва ли не обязательна.
Дальше арифметика. Знаю, не все её любят. Бывает даже стыдно смотреть в глаза взрослым людям, которые в разработке видят интуитивное искусство, а не инженерство с линейкой, но… простите.

Предположим, сервис 1K раз ходит в базу для того, чтобы каждый раз вытащить 1K строк, с которыми что-то надо сделать в функции nextSomething(). Да хоть из сырой строки сделать объект. Получаем 1M вызовов функции. Очень штатное по нынешним временам.
Предположим, функция написана неплохо, но всё же есть потеря 1ms потому, что… да до фига причин. Лишний лог пишет. Или вместо StringBuilder использует String в развесистой конкатенации переменных. Или массив создаёт на N элементов, а в процессе раздувает до N в квадрате. Короче, 1ms теряется. Ну и ладно, да? Одна туда, одна сюда, не жалко.
Это 1M ms. Это 16 минут. Пусть 15 даже для округлости. Дважды в сутки эта тысяча по тысяче выполнится и ой, 30 минут пустого прогрева окружающей среды. 15 часов в месяц.
Сколько таких функций в сервисе? На скольких инстансах раскатан этот сервис? Достаточно 10 функций и 5 инстансов, чтобы при таком раскладе в трубу ежемесячно вылетал месяц.
Всё ещё игнорируем тюнинг в 1ms, а? А если за этот месяц платить будет не работодатель, но вы? Будет интереснее?

Даже если не брать во внимание финансовый фактор (ах, как это удобно), остаётся некоторая профессиональная тонкость. Правильные разработчики пишут эффективный код. Среди прочего это ТАКЖЕ (капсом для тех, у кого человек может быть либо здоровым, либо богатым, но не здоровым И богатым одновременно) работающий максимально быстро код, использующий возможности окружения на всю катушку.
Для написания такого кода надо очень хорошо знать язык, интерпретаторы / компиляторы, операционные системы и прочее, прочее, прочее. Так вот, наблюдение: абсолютно (подчеркну: абсолютно) все разработчики, от которых я слышал критику в сторону микротюнинга, очень плохо знали матчасть ниже синтаксиса языка. Зачастую и в синтаксисе плавали. А вот бойцы, старательно выгрызающие эти злосчастные миллисекунды, наоборот, что в теории, что в практике подкованы были очень, очень хорошо.
Случайное совпадение? Безусловно.

Закругляюсь.
Код, впустую гоняющий сервера, подобен древней китайской ТЭС на угле.
Возьмите исходник. Возьмите профайлер. Найдите узкое место. Посимвольно разберите его, для каждого символа отыскав толкование в спецификациях. Попробуйте улучшить. И ещё. И ещё.
Может быть, вам понравится результат и вы захотите улучшить остальные места, чем и займётесь на выходных. Глядишь, в итоге половину инстансов можно будет погасить, что благотворно скажется на экологии планеты.
Ведь хорошо же, когда вместо одной пустой миллисекунды (и сотен ДЦ для таких “потребителей”) появляются зелёные деревья с разноцветными птичками. Очень хорошо.

Книги: Reactive Java Programming

Reactive Java Programming
Andrea Maglie.
Reactive Java Programming.
Apress, 2016.
Небольшая книга-справочник про RxJava 1.x. Подходит для быстрого знакомства, снабжена удобными и наглядными marble diagrams (кстати, и в сети есть версия, тоже вот прям ня: http://rxmarbles.com), да и только.
В плюсах быстрый вход в тему и наглядность.
В минусах очень сокращённый текст, местами слишком синтетические примеры, местами я ваще не понял цимес решений, хоть и не дурак, кажется.
Также считаю спорным упоминание о том, что RxJava про функциональное программирование. Нет, не про функциональное. Это именно “a library for composing asynchronous and event-based programs by using observable sequences”, о чём и сказано в README.
Можно читать, можно не читать.
Прямо к разработке книга не относится, но почитать её полезно.

О заложниках работы

До меня долго доходило. Вот в самом деле долго. А в этот раз настигло просветление. Впервые за много лет хоть и временно (на пару недель), но безработный (пусть и условно, раз вовсю зубрю матчасть). Впервые я никому ничего не должен, не отвечаю на звонки мониторингов, не читаю рабочие чаты, не проверяю рабочую почту и вообще не делаю многое из того, что въедается под кожу и становится первым, что утром после открытия глаз совершаешь до первой сигареты и первого кофе.
И это офигительно. Пока вас работа не достанет до печени, не оцените. Когда оцените, не забудете.
Благодаря такому просветлению, к которому зрел не один день всё-таки, несколько очередных мудростей.

Во-первых, вы взрослый человек (надеюсь). И не в армии (возможно). И не давали клятвы / расписки (надеюсь). Потому простое — вы не должны делать то, что не нравится. Вот как с определённого возраста можно хоть ящик пломбира сожрать, так можно встать и выйти, если считаете, что текущее место чем-либо не подходит, а поменять параметры никак. Обычно вы наняты работодателем. И отношения достаточно строго регламентируются. Ему не нравится — увольняет. Вам не нравится — увольняетесь. Иногда это единственный способ хоть как повлиять на ситуацию.
Во-вторых, жизни вне вашей текущей работы много. Очень разной жизни. Бойцы из небольших империй (Яндекс, Mail.ru, FB, Google, etc) склонны ограничивать свой мир вот этим вот всем. Дальше некуда идти (ну разве что из российских компаний любят заводить трактор в Лондон и Дублин). Ну… слушайте, что по своему опыту, что по опыту коллег из других организаций ясно вижу, что именно в таких империях жизни всё меньше. Вот того “духа стартапа” (который не про критикалы в продакшене). Если вы не ключевой сотрудник ключевого направления с ключевыми научными работами, скорее всего, вы клепаете ровно те же строчки кода, что и бойцы из тысячи небольших конторок. Но над ними нет вертикали согласований, фашистских процессов и всего интересного, что интересно Газпрому какому-нибудь. Поднимите голову и осмотритесь. Всегда есть выбор.
В-третьих, вы тратите жизнь. В 25 лет не думаешь об этом совершенно. Лишь бы наработать опыт и “вау, я впервые делаю импорт CSV, это так прикольно!” В 35 лет… последние месяцы работы я ходил в офис как на каторгу. Каждый день думал о том, чем и зачем занимаюсь. Очень помогли записи ежедневной занятости. И вот… полезно проговорить вслух. Я программист. Я мечтал быть им с 7 лет. Учился и учусь специальности N лет. Сделал X сервисов. Поддерживал Y сервисов. Прочёл A книг и написал B тысяч строк кода. Сейчас я каждый день занимаюсь этим, вот этим и вон тем. И завтра буду. И послезавтра. А потом умру и с облака буду думать о том, что свою мечту потратил на. Если вам норм, то всё хорошо. Если колдобит и косорожит, увольняйтесь, будет только хуже.
В-четвёртых, зачем? Это есть в предыдущем пункте, но настолько важно само собою, что выделил. Период безработицы (не отпуска!) даёт возможность вдумчиво ответить на этот вопрос. От ответа строить жизнь дальше. Деньги? Карьера? Стабильность? Новизна? Страна пребывания? Любовь к определённым задачам или технологиям? Суть в том, что только после честного ответа и сознательного выбора работы у вас выйдет если не раскрыться, то хотя бы работать с полной отдачей. Но ответить получится только после сброса с себя текучки и рабочей рутины. Освободиться. Вдохнуть свободы. Задуматься. Потому отпуск не поможет. Разве что интернет отключить и ноут бабушке на хранение сдать.
В-пятых, всё будет хорошо. Никогда не сочувствовал увольняющимся и не жалел об уходе. Люди уходили в лучшее и, насколько слежу за судьбой, так или иначе, но у них получилось. Увольнение — заряд бодрости и возможность начать заново (но уже с опытом набившего шишки). Потому ничего не бойтесь, статистика на вашей стороне.

Увольняйтесь и увольняемы будьте.
Аминь.

Кому руководить разработчиками

Мне иногда настолько не везло с руководителями (справедливости ради, им со мною ровно так же), что собрал почти полный набор anti-patterns. Судя по общению с коллегами по цеху, для разработки такой набор норма. Вызвано тем, что руководители зачастую — просто вот те же бойцы, которых обстоятельства выдёргивают из грядки. Отсюда всё и вытекает.
Итак, список. Если какой-либо из пунктов относится к вам, поздравляю, подчинённым с вами фигово. Особо мнительным подарок: нет, человека, в котором ВСЕ эти пункты, я пока живьём не видел. Надеюсь, не увижу.

Незнание. Ничего учить не надо. Вы уже руководитель. Руководитель мудро руководит, а не зубрит учебники. На статьи нет времени. Надо подписать стопку бумажек. Почаще проговаривайте вслух утверждения, от которых фейспалмят даже студенты первого курса (“в военное время значение Пи…”, только там шутка, а вы всерьёз). Так завоюете профессиональное уважение подчинённых. Ведь всегда интересны люди с самобытным взглядом на математику и логику, ну и на разработку, конечно же.

Больше встреч. Подчинённый — он как рядовой в армии. Ему наверняка нечем заняться, потому пусть сидит на встречах. Встреча о планировании встреч планирования встреч на десять человек длительностью два часа каждый чётный день месяца будет в самый раз. Для начала. Потом встречи о результатах встреч. И встречи для планирования дальнейших встреч о результатах встреч. Так подчинённые поймут, что у руля власть, для которой “процессы” не просто слово.

Меньше прозрачности. Разработчик должен разрабатывать. Всё. Об остальном позаботится вождь. Разработчик не должен знать планы. Цели. Стратегии. Приоритеты. Причины приоритетов. Кадровые перестановки. Решения. События. Договорённости. Финансы. Всё это лишь смущает неокрепший ум подчинённого, потому должна быть информационная стена. Получил утром рабочий паёк — шуруй в забой, там твоя область ответственности. Так подчинённые научатся не отвлекаться. Ну и вообще загадочность — это так прикольно.

Больше эмоций. Офис — место, в котором вы можете раскрыться. Как личность. Если чешется пятка, покричите на фронтендера. Если голова болит, дайте в челюсть бекендеру. На админов изливайте депрессию просто так. Менеджеров изводите шипящим голосом, ведь не просто ж так у вас нос заложен. Пусть все знают и понимают, что они не на рабочее место зашли, но на вашу территорию. Так подчинённые станут вам ближе. Чем вы громче, тем они ближе. Именно так это работает.

Работодатель не нужен. Вам платят деньги не за то, чтобы вы действовали в интересах работодателя. ОН должен быть благодарен уже за то, что такой большой специалист согласился присутствовать. Потому работа будет делаться та, что интересна вам. И сотрудников вам не дали, но подарили. Потому пусть тоже делают то, что вам интересно. Так сотрудники проникаются важностью того, что делают.

Пользователи не нужны. Пользователи все дураки. Вот поголовно дураки. И академик Пётр Иванович дурак тоже. Я, Вася, умнее всех их вместе взятых. Потому кушать будут то, что дам, а не то, что просят. Вон Apple убедил же всех, что у них лучшее железо. И Форд про лошадок говорил (не говорил). Потому идите в жопу, пользователи. Так сотрудники научатся выбирать правильные приоритеты задач.

Волки! Волки! Если сотрудник три раза прокричал “волки!”, сотрудник шутит. Пусть даже все три раза прибегали серые братья. Не надо слушать подчинённых. Прислушиваться не надо. Вообще надо меньше с ними разговаривать, а если чего услышите, так сразу забыть. К слову, забывчивость — ваш лучший друг. Если чего не помню, так того и не было. Ведь так приятно это чудесное состояние удивления, когда внезапно что-то оказывается внезапным. Так сотрудники приучаются к самостоятельности. Ну и не отвлекают своими глупостями от важного, конечно.

Говорите голосом. Ничего не записывайте. Не пишите письма. Не пользуйтесь мессенджерами. Не ведите документацию. Только голос. Мало того, что не барское это дело (буквы набирать-то!), так ещё ж эти жулики потом придираться будут. То задача не так поставлена. То вообще была другая задача. То задачи и не было. То была, но не задача. То поток сознания, а не внятная речь. Нефиг. Вы очень занятой человек, а модуляции голосом здорово дополняют любую задачу. Так подчинённые приучаются по интонации угадывать нужное, да и память тренируют. Полезно же.

Чаще и детальнее вмешивайтесь. В этом мире из миллиона разработчиков только вы обладаете правильным взглядом на разработку. Потому старайтесь чаще указывать подчинённым на недопустимость пробела перед скобкой и на то, что однобуквенных переменных никогда, никогда не должно быть! Никогда! Нигде! Зло! Даже в приложении обсчёта конструкций по формулам справочника зло! Никак иначе. Если этих балбесов хоть на неделю оставить без присмотра, такого наворотят, что потом год разгребать. Так подчинённые привыкают ощущать ежесекундную поддержку.

Уф. Пожалуй, выписал самое бесячье (самый неадекватный ад не пишу, в нормальных конторах нравы иные). В тексте оно веселее, конечно, но если день за днём разные формы переживать живьём, как-то менее весело. Только потом с коллегами за рюмкой обмениваться радостью новых открытий остаётся.
Хороших вам руководителей, не болейте.