в компиляторы, интерпретаторы и среды выполнения. Эти формы оптимизации помогают коду даже без вашего ведома (я очень рекомендую прочитать, как именно оптимизирует себя ваш язык программирования, это будет очень полезно).

Разные области разработки программного обеспечения требуют разной степени оптимизации. Есть определенный баланс: оптимизируя код, вы часто жертвуете стройностью его логики, красотой реализации, удобством архитектуры или частью функций системы.

Из этого следует первое правило: никогда не начинайте оптимизацию до того, как код будет удовлетворять всем требованиям проекта. Дональд Кнут (пожалуйста, прочитайте про этого прекрасного человека) сформулировал это правило так: «Преждевременная оптимизация – корень всех зол»[3] – и был, несомненно, прав. В вопросах оптимизации необходимо идти от обратного: не от отсутствия кода к его появлению, а от существующего кода к его упрощению и ускорению.

Второе правило оптимизации: убедитесь в том, что вы оптимизируете нужный код.

Прежде чем приступать к любой оптимизации, следует как минимум сделать профилирование кода. Необходимо знать все медленные места проекта, все бутылочные горлышки (bottlenecks, да, ознакомьтесь с этим). Чем больше вы получите информации о проекте, тем лучше сможете проанализировать и спланировать дальнейшую оптимизацию.

Как уже говорилось, чаще всего оптимизация на готовом проекте представляет собой баланс: на одной чаше весов – скорость и безотказность работы после оптимизации, на другой – простота понимания кода, удобство его использования или часть функций, от которых придется отказаться. Вы не сможете склонить чашу весов ни в одну из сторон, пока проект не будет удовлетворять всем требованиям и пока вы не будете знать, какие именно места в системе делают ее медленной и неоптимальной.

Вопрос о необходимости оптимизации также зависит от того, что именно вы собираетесь ускорить и чем можете пожертвовать, чтобы сохранить время, нервы и волосы вашего продакт-менеджера. Допустим, вы разрабатываете сайт, который позволяет одним пользователям загружать фотографии себе в ленту, а другим – просматривать их (нет, мне это ничего не напоминает, а вам?).

Вы провели профилирование и выяснили, что в системе есть два медленных места: из-за сложной обработки данных замедляется регистрация новых пользователей, а из-за некорректно выбранного формата хранения довольно медленно идет выдача загруженных фотографий. Очевидно, что для пользователей выдача фотографий гораздо важнее и оптимизация требуется в первую очередь здесь. В реальных проектах приоритет оптимизации не всегда будет определяться с такой очевидностью, поэтому необходимо тщательно подходить к проблеме выбора.

Оптимизация часто приводит код к менее логичному виду, иногда усложняет его, иногда чрезмерно упрощает, лишая его абстракций, элегантных решений. Это нормально: задача оптимизации – сделать код максимально продуктивным, и у этого есть цена, которую вы должны заплатить.

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

Каждая оптимизация уникальна. В одном случае это будут некорректные индексы в базе данных, которые вы поправите одним запросом. В другом вы уткнетесь в несовершенство операционной системы, в рамках которой работает проект, и потратите не один день на поиск способа сделать код быстрее. Оптимизация – это чаще всего не набор конкретных действий, а творческий подход к коду в попытке сделать его более производительным.

Тезисы

■ Не надо оптимизировать весь код.

■ «Преждевременная оптимизация – корень всех зол».

■ Выделяйте приоритеты оптимизации.

■ Изучайте и используйте технические способы оптимизации.

■ За оптимизацию всегда надо платить (логичностью кода, удобством, потерей функций).

Задание

Профилируйте проект, определите места, которые требуют оптимизации (если их не обнаружилось, значит, либо у вас идеальный проект, либо вы плохо искали). Попробуйте расположить найденные медленные места в порядке убывания важности исходя из функций вашего проекта: что должно быть оптимизировано сразу? Что можно отложить на потом? Попробуйте оптимизировать участок кода, в котором вы разбираетесь лучше всего. Проведите профилирование еще раз, чтобы убедиться, что новое решение более производительно. Проанализируйте изменения и скажите, стал ли код более читаемым, стал ли более сложным в дальнейшей поддержке, не пришлось ли вам срезать несколько углов и избавиться от чего-то не слишком важного ради скорости выполнения?

История из жизни

История, вспоминая которую можно и усмехнуться, и всплакнуть. В одном из проектов мы действительно провели невероятную «оптимизацию», но скромно умолчали о ней. В нескольких критически важных местах системы, которые должны были выполняться очень быстро, обнаружились оставленные кем-то из разработчиков отладочные вызовы функции sleep. Эта функция останавливает выполнение программы на указанное время, тем самым замедляя любой процесс на указанное время. В официальных отчетах мы отметили, что скорость работы приложения повышена, однако предпочли не раскрывать, каким именно образом. В любом случае это был самый быстрый и качественный способ оптимизации, с которым я сталкивался. Удалить несколько строк кода и получить немедленный прирост скорости – не об этом ли мечтает каждый разработчик?

Люди

Этот раздел – об общении с людьми, о том, как выстраивать деловые отношения, как приспособиться к работе в коллективе. Я затрону социальные вопросы, проблемы баланса между работой и общением.

Разработчики постоянно общаются с разными людьми: с коллегами, начальством, а также с теми, кто максимально далек от разработки программного обеспечения и с трудом отличает браузер от операционной системы. Вы должны уметь найти верный способ объяснить им, чем вы занимаетесь. Навык общения крайне важен для профессионального (а еще в большей степени карьерного) роста.

Как разработчик вы в первую очередь должны уметь писать код. Но этого мало. Умение вести диалог, объяснять свои мысли, предлагать собственные решения и высказывать несогласие – все это даст вам огромные возможности профессионального роста.

Контекст и коммуникация

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

Ремесло разработчика сложное, это факт. В голове у вас должны умещаться абстракции, логика работы проекта, особенности требований, подходящие алгоритмы, потенциальные ошибки и многое-многое другое. Все это требует внимания и сосредоточенности, которые так легко потерять, если внезапно задуматься на постороннюю тему.

Вы должны оберегать себя от внешних раздражителей. Наушники, режимы «do not disturb» в программном обеспечении, отдельный кабинет или комната, где вас никто не станет дергать. Чем больше вы работаете, тем лучше понимаете, как обеспечить себе максимальный комфорт на рабочем месте.

На многих проектах полагаются обязательные митинги (совещания), обсуждения или иные способы коммуникации. Иногда это вызвано методологией разработки, иногда избыточным количеством менеджеров, которым больше нечем заняться. Часто отказаться от участия в них просто нельзя, а порой они даже бывают полезны, но помните: ваш основной приоритет – работа над кодом.

Если вы понимаете, что излишняя коммуникация только вредит вашей работе, обсудите это с менеджером или старшими разработчиками. Скорее всего, вы сумеете договориться о возможности избегать непродуктивного общения, чтобы сосредоточиться на работе.

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

Это же относится и к общению в рабочих чатах, мессенджерах или в офисе: определите для себя комфортный уровень коммуникации и придерживайтесь его – отключайте чаты, попросите коллег не беспокоить вас, если понимаете, что они мешают сосредоточиться.

Тезисы

■ Оберегайте свое спокойствие и рабочий контекст.

■ Проанализируйте, нравится