Отрывок из книги «От джуна до сеньора: как стать востребованным разработчиком» Владимира Швеца, выпущенной издательством «Альпина Паблишер».
Код ради кода
Открою вам секрет: разработчики любят код. Можно сколько угодно делать вид, будто мы приходим на работу за зарплатой, но если вы настоящий разработчик, то знаете, о чем я говорю. Нам нравится код, нравится создавать что-то из ничего. И мы любим играть: с новыми технологиями, идеями и подходами, с новыми языками программирования, библиотеками и инструментами.
Если вы с энтузиазмом познаете новое, с удовольствием разбираетесь в подходах к разработке или обожаете писать свои pet projects, будьте осторожны: так можно перепутать работу и игру. Нет ничего лучше, чем любовь к своей работе, и ваша тяга к новым знаниям — это прекрасно (я бы вас даже обнял, но руки заняты набором этого текста).
Однако работа на коммерческом проекте, с задачами, которые поставлены другими людьми, с финансовыми потерями или, наоборот, выигрышами накладывает свои обязательства. Не поддавайтесь искушению играть с кодом на работе.
Вам может захотеться встроить в проект Lua-интерпретатор или написать микросервис на Scala, но до конца ли вы уверены, что это решение — результат анализа потребностей проекта? Может, вам просто хочется испробовать новый язык или технологию.
Действительно ли эта новая библиотека, которую так хочется использовать, нужна проекту, или вам просто любопытно, как она работает?
Старайтесь разделять любовь к знаниям и профессиональные навыки. Поверьте мне: даже в рамках несколько наскучившего вам проекта есть масса вещей, которые вы можете улучшить, не применяя десяток новых технологий. Не поддавайтесь желанию испробовать каждую технологию, которую знаете, на своем рабочем проекте.
Ваша работа — не супермаркет игрушек, поэтому вы должны ответственно подходить к тому, что и как использовать. Никто не станет сдвигать рассчитанные ETA, чтобы вы могли узнать, а так ли продуктивен Go в действительности. Никто не будет мириться со штрафами от клиентов, пока вы проверяете, подходит ли Rust в качестве альтернативы языку программирования проекта (разве что вам поставили такую задачу, если это так — я очень за вас рад).
Вам нужно уметь работать в рамках и интересах проекта для его коммерческого успеха. Жажда знаний и страсть к новому пригодятся вам даже в таких условиях, просто старайтесь разграничить личную заинтересованность в разработке и требования заказчиков.
Задание
Представьте, что ваш текущий проект —«песочница» и здесь можно пробовать любые технологии и языки. Черт, да и вы можете использовать по языку на каждый имеющийся у вас сервис! Подумайте, насколько сложно было бы совместить разные подходы к разработке, архитектуре, инструментам в одном проекте. Попробуйте оценить, насколько бы затянулась по времени реализация одной из ваших задач, если бы для этого использовался другой язык программирования.
История из жизни
Я люблю языки программирования, люблю пробовать каждый, чтобы понять, каков он, чем он может быть интересен. И так как время мое не резиновое, мне всегда приходится искать способ уместить максимум интереса в минимум времени.
С какого-то момента, пробуя новый язык, я стал делать с его помощью «Франкенштейна» — небольшой проект, буквально несколько файлов, в которые старался уместить все особенности языка, используя их так, чтобы они делали хоть что-то осмысленное. Со временем это стало забавной традицией и незамысловатым способом поднять себе настроение.
Оптимизация
Оптимизация — это способ сделать уже написанный код более быстрым, менее требовательным к ресурсам и более отвечающим нуждам задачи, которую он выполняет. Оптимизация возможна почти для любого написанного кода, но в большинстве случаев она нужна только в конкретных местах проекта.
Задачи оптимизации кода, его быстродействия крайне важны, и отчасти вы уже оптимизируете код, даже не осознавая этого. Многие языки программирования включают механизмы оптимизации в свои инструменты: в компиляторы, интерпретаторы и среды выполнения. Эти формы оптимизации помогают коду даже без вашего ведома (я очень рекомендую прочитать, как именно оптимизирует себя ваш язык программирования).
Разные области разработки программного обеспечения требуют разной степени оптимизации. Есть определенный баланс: оптимизируя код, вы часто жертвуете стройностью его логики, красотой реализации, удобством архитектуры или частью функций системы.
Из этого следует первое правило: никогда не начинайте оптимизацию до того, как код будет удовлетворять всем требованиям проекта. Дональд Кнут (пожалуйста, прочитайте про этого прекрасного человека) сформулировал это правило так: «Преждевременная оптимизация — корень всех зол» — и был, несомненно, прав.
В вопросах оптимизации необходимо идти от обратного: не от отсутствия кода к его появлению, а от существующего кода к его упрощению и ускорению.
Второе правило оптимизации: убедитесь в том, что вы оптимизируете нужный код. Прежде чем приступать к любой оптимизации, следует как минимум сделать профилирование кода. Необходимо знать все медленные места проекта, все бутылочные горлышки (bottlenecks, да, ознакомьтесь с этим). Чем больше вы получите информации о проекте, тем лучше сможете проанализировать и спланировать дальнейшую оптимизацию.
Как уже говорилось, чаще всего оптимизация на готовом проекте представляет собой баланс: на одной чаше весов — скорость и безотказность работы после оптимизации, на другой —простота понимания кода, удобство его использования или часть функций, от которых придется отказаться.
Вы не сможете склонить чашу весов ни в одну из сторон, пока проект не будет удовлетворять всем требованиям и пока вы не будете знать, какие именно места в системе делают ее медленной и неоптимальной.
Вопрос о необходимости оптимизации также зависит от того, что именно вы собираетесь ускорить и чем можете пожертвовать, чтобы сохранить время, нервы и волосы вашего продакт-менеджера. Допустим, вы разрабатываете сайт, который позволяет одним пользователям загружать фотографии себе в ленту, а другим — просматривать их.
Вы провели профилирование и выяснили, что в системе есть два медленных места: из-за сложной обработки данных замедляется регистрация новых пользователей, а из-за некорректно выбранного формата хранения довольно медленно идет выдача загруженных фотографий.
Очевидно, что для пользователей выдача фотографий гораздо важнее и оптимизация требуется в первую очередь здесь. В реальных проектах приоритет оптимизации не всегда будет определяться с такой очевидностью, поэтому необходимо тщательно подходить к проблеме выбора.
Оптимизация часто приводит код к менее логичному виду, иногда усложняет его, иногда чрезмерно упрощает, лишая его абстракций, элегантных решений. Это нормально: задача оптимизации — сделать код максимально продуктивным, и у этого есть цена, которую вы должны заплатить.
Технически оптимизация будет напрямую зависеть от того, каким языком программирования вы пользуетесь, какие применяете библиотеки и компоненты, какие инструменты работают в проекте. Возможно, библиотека, которую вы используете, медленная. Возможно, вы неоптимально используете какой-либо из ресурсов системы. Возможно, вы где-то забыли отладочный код, замедляющий проект.
Каждая оптимизация уникальна. В одном случае это будут некорректные индексы в базе данных, которые вы поправите одним запросом. В другом вы уткнетесь в несовершенство операционной системы, в рамках которой работает проект, и потратите не один день на поиск способа сделать код быстрее.
Оптимизация — это чаще всего не набор конкретных действий, а творческий подход к коду в попытке сделать его более производительным.
Задание
- Профилируйте проект, определите места, которые требуют оптимизации (если их не обнаружилось, значит, либо у вас идеальный проект, либо вы плохо искали).
- Попробуйте расположить найденные медленные места в порядке убывания важности исходя из функций вашего проекта: что должно быть оптимизировано сразу? Что можно отложить на потом?
- Попробуйте оптимизировать участок кода, в котором вы разбираетесь лучше всего.
- Проведите профилирование еще раз, чтобы убедиться, что новое решение более производительно.
- Проанализируйте изменения и скажите, стал ли код более читаемым, стал ли более сложным в дальнейшей поддержке, не пришлось ли вам срезать несколько углов и избавиться от чего-то не слишком важного ради скорости выполнения?
История из жизни
История, вспоминая которую можно и усмехнуться, и всплакнуть. В одном из проектов мы действительно провели невероятную «оптимизацию», но скромно умолчали о ней.
В нескольких критически важных местах системы, которые должны были выполняться очень быстро, обнаружились оставленные кем-то из разработчиков отладочные вызовы функции sleep. Эта функция останавливает выполнение программы на указанное время, тем самым замедляя любой процесс на указанное время.
В официальных отчетах мы отметили, что скорость работы приложения повышена, однако предпочли не раскрывать, каким именно образом. В любом случае это был самый быстрый и качественный способ оптимизации, с которым я сталкивался.
Удалить несколько строк кода и получить немедленный прирост скорости — не об этом ли мечтает каждый разработчик?
Десять раз спроси, один — напиши
Разработчик почти всегда находится в поиске более качественного решения задачи, над которой работает. Если вы пишете код исключительно для себя, это отчасти упрощает задачу (или значительно усложняет, спасибо тебе, проклятый перфекционизм).
Однако если вы разрабатываете код по чьим-то требованиям, то почти всегда будете располагать неполной информацией. У вас будет масса вопросов, непонятных или не до конца известных условий и особенностей продукта, которые необходимо выяснить.
Никогда не бойтесь и не стесняйтесь спрашивать обо всем, что считаете нужным при решении задачи. Нет ничего более полезного, чем полная информация о проблеме, которую вам необходимо решить. Любое предположение, не подкрепленное верными данными, может обернуться ошибкой. Любое белое пятно в требованиях может привести к необходимости выкинуть половину готового кода и начать писать его заново.
Обилие вопросов может смутить менеджеров, заказчика или старших разработчиков, но помните: вы занимаетесь разработкой не для того, чтобы о вас хорошо или плохо думали, а ради качества продукта, ради профессионализма и карьеры.
Хирург не начинает операцию без знаний и опыта, точно так же и вы не можете приступить к работе, не выяснив досконально, с чем придется столкнуться.
Старайтесь упростить себе работу. Не заданный вовремя вопрос замедлит выполнение задачи либо в процессе самого решения, либо позже, когда вам надо будет вносить дополнения и изменения, которые, в свою очередь, могут спровоцировать новые ошибки.
Задание
- Составьте максимально подробный список вопросов, постарайтесь представить общую картину проблемы и ее потенциального решения.
- Задайте эти вопросы тому, кто поставил задачу. Попробуйте заранее определить, какие дополнительные сложности могут вас ждать.
История из жизни
Один раз я взял небольшой (и потенциально быстрый) заказ на разработку сайта с астрологическими прогнозами. Сказать, что я задолбал заказчика вопросами о том, как устроены гороскопы и от чего будет зависеть выдача пользователям, значит не сказать ничего.
В силу гороскопов я так и не поверил, но у меня еще долгое время на столе лежал ворох бумаг с выкладками по знакам зодиака и воздействию на каждый из них положения Луны.
Винтик в механизме
Долгая работа на одном проекте или в одной компании заставляет наши мозги ржаветь. Мы используем одни и те же технологии, работаем по одним и тем же установленным в компании правилам, применяем одни и те же методологии и подходы.
В какой-то момент это может даже начать доставлять удовольствие: все становится достаточно знакомым, чтобы работу можно было выполнять быстро, просто и шаблонно. И ровно в этот момент наш мозг начинает ржаветь.
Труд разработчика многогранен и интересен. Нам приходится решать сложные задачи, находить новые подходы и разбираться в порой совершенно безумных требованиях заказчиков. Однако постоянное повторение одних и тех же решений, работа в одной и той же области требований, с одними и теми же технологиями нередко приводит к тому, что наши навыки становятся узкоспециализированными, заточенными под один набор задач.
В некоторых областях разработки программного обеспечения это станет плюсом, но если вы понимаете, что теряете профессиональную хватку, — пришло время помогать себе.
Ощущение того, что вы лишь винтик в механизме, характерно для разработчиков больших компаний, работа каждого из которых сосредоточена на конкретной подсистеме или части функций проекта. Разработчики могут годами видоизменять одни и те же части кода, теряя представление о том, как система функционирует в целом. Кому-то из вас такая работа будет по душе, но кто-то может начать чувствовать постоянное давление и растущее ощущение своей бесполезности.
Давайте оговоримся сразу: любая работа, которую вы делаете, важна и нужна. Даже не пробуйте спорить с этим и предполагать «другие варианты». Примите это как безусловный факт. Однако вы должны помочь себе. Ваши амбиции (я употребляю это слово в самом положительном смысле), ваш опыт требуют нового. Они требуют, чтобы вы развивались, им нужны ваша помощь и участие.
Знания и опыт — это то, что делает вас профессионалом. Помогите себе: начните заново пополнять их. Пробуйте направления, которыми раньше никогда не занимались.
Вы занимаетесь веб-разработкой? Научитесь писать на ассемблере. Создаете мобильные приложения? Попробуйте написать свою мини-игру под Linux.
Однако замечу: выбирайте то, к чему испытываете интерес. Нет ничего хуже, чем заставлять себя заниматься тем, что не по душе. Знания никогда не бывают бесполезными, особенно в нашей индустрии.
Вы думаете, что разобрались в том, как работает сетевой стек, но это вам никогда не пригодится? Просто подождите. Думаете, что вам совершенно ни к чему знать, в чем разница между stack и heap? Года не пройдет, как вы столкнетесь с этим в работе.
Есть вероятность, что, даже получая новые знания, вы все равно будете чувствовать себя как в клетке. Такое ощущение часто возникает, если компания не дает пространства для роста и развития. Возможно, руководство не считает это важной или нужной частью вашей рабочей деятельности; возможно, ему выгоднее задействовать вас прицельно на конкретном проекте или части проекта.
В любом случае, если вы постоянно чувствуете себя в западне, подумайте, а так ли полезна для вас работа в компании, которая не хочет видеть профессиональный рост и новый опыт своего сотрудника.
Задание
Попробуйте честно ответить себе на вопрос: вы чувствуете, что на текущем месте работы получаете новые знания и опыт? Не ощущаете ли вы себя в западне рутинной, повторяющейся работы? Если понимаете, что начали буксовать в профессиональном развитии, попробуйте изучить что-то новое: язык программирования, подход к разработке — что угодно, что вызывает у вас интерес.
Если же вы пробуете снова и снова, но все равно возвращаетесь к работе, где вас используют как инструмент для выполнения одних и тех же задач, задумайтесь: заслуживают ли ваш профессиональный рост и карьера такой стагнации?
История из жизни
Самой большой отдушиной для меня становилось понимание того, что вся магия, которую я могу воплотить в коде, только в моих руках. Ничто извне не может помешать мне написать новое, создать что-то интересное из ничего, из набора слови цифр.
Когда мне начинало казаться, что я просто занимаю определенное место в скучном, большом механизме, я начинал писать для себя, по вечерам, после работы, ночью. И это всегда помогало. Я старался никогда не позволять себе быть узником собственных мыслей.
