Вам нередко будут встречаться разработчики, которые считают, что нашли идеальный способ что-либо сделать. Относитесь к таким утверждениям с изрядной долей скепсиса. Наша индустрия очень быстро изменяется, эволюционирует. Попытки использовать одни и те же подходы на протяжении долгого времени приведут к тому, что система будет деградировать, становиться неподдерживаемой и медленной. Многие инструменты в момент своего появления были уникальны и незаменимы, однако постепенно становились все более бесполезными (прости, jQuery, но это правда).
Будьте гибкими, не позволяйте опыту (даже личному) вставать на пути к качественному коду.
Тезисы
■ Серебряной пули не существует.
■ Всегда ищите лучшие варианты, но не бегите за трендами.
■ Не останавливайтесь на одном решении, старайтесь сделать лучше.
Задание
Проанализируйте код вашего проекта и найдите инструменты, библиотеки или компоненты, которые используются достаточно давно. Узнайте, насколько они актуальны, поддерживаются ли, какие для них есть альтернативы.
История из жизни
Не проходило и нескольких лет, чтобы мир разработки не получал в свое распоряжение какую-нибудь новую блестящую игрушку и целую армию ее фанатов, утверждающих, что ВОТ УЖ ТЕПЕРЬ ВСЕ ПРОБЛЕМЫ БУДУТ РЕШЕНЫ. Однако чем дольше находишься в этой индустрии, тем чаще видишь одни и те же технологии, приправленные новой маркетологией. Черт, было время, когда и я думал, что C++ сможет решить любую мою проблему. Идеального кода нет, как и идеальных решений, так что отбросим невротический поиск абсолюта: «делай что должно – и будь что будет».
Код ради кода
Открою вам секрет: разработчики любят код. Можно сколько угодно делать вид, будто мы приходим на работу за зарплатой, но если вы настоящий разработчик, то знаете, о чем я говорю. Нам нравится код, нравится создавать что-то из ничего. И мы любим играть: с новыми технологиями, с новыми идеями и подходами, с новыми языками программирования, с новыми библиотеками и инструментами.
Если вы с энтузиазмом познаете новое, с удовольствием разбираетесь в подходах к разработке или обожаете писать свои pet projects, будьте осторожны: так можно перепутать работу и игру. Нет ничего лучше, чем любовь к своей работе, и ваша тяга к новым знаниям – это прекрасно (я бы вас даже обнял, но руки заняты набором этого текста). Однако работа на коммерческом проекте, с задачами, которые поставлены другими людьми, с финансовыми потерями или, наоборот, выигрышами накладывает свои обязательства.
Не поддавайтесь искушению играть с кодом на работе. Вам может захотеться встроить в проект Lua-интерпретатор или написать микросервис на Scala, но до конца ли вы уверены, что это решение – результат анализа потребностей проекта? Может, вам просто хочется испробовать новый язык или технологию? Действительно ли эта новая библиотека, которую так хочется использовать, нужна проекту, или вам просто любопытно, как она работает?
Старайтесь разделять любовь к знаниям и профессиональные навыки. Поверьте мне: даже в рамках несколько наскучившего вам проекта есть масса вещей, которые вы можете улучшить, не применяя десяток новых технологий. Не поддавайтесь желанию испробовать каждую технологию, которую знаете, на своем рабочем проекте.
Ваша работа – не супермаркет игрушек, поэтому вы должны ответственно подходить к тому, что и как использовать. Никто не станет сдвигать рассчитанные ETA, чтобы вы могли узнать, а так ли продуктивен Go в действительности. Никто не будет мириться со штрафами от клиентов, пока вы проверяете, подходит ли Rust в качестве альтернативы языку программирования проекта (разве что вам поставили такую задачу, если это так – я очень за вас рад).
Вам нужно уметь работать в рамках и интересах проекта для его коммерческого успеха. Жажда знаний и страсть к новому пригодятся вам даже в таких условиях, просто старайтесь разграничить личную заинтересованность в разработке и требования заказчиков.
Тезисы
■ Разработчики любят код и новизну.
■ Не играйте с кодом на работе.