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

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

Будьте гибкими, не позволяйте опыту (даже личному) вставать на пути к качественному коду.

Тезисы

■ Серебряной пули не существует.

■ Всегда ищите лучшие варианты, но не бегите за трендами.

■ Не останавливайтесь на одном решении, старайтесь сделать лучше.

Задание

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

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

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

Код ради кода

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

Если вы с энтузиазмом познаете новое, с удовольствием разбираетесь в подходах к разработке или обожаете писать свои pet projects, будьте осторожны: так можно перепутать работу и игру. Нет ничего лучше, чем любовь к своей работе, и ваша тяга к новым знаниям – это прекрасно (я бы вас даже обнял, но руки заняты набором этого текста). Однако работа на коммерческом проекте, с задачами, которые поставлены другими людьми, с финансовыми потерями или, наоборот, выигрышами накладывает свои обязательства.

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

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

Ваша работа – не супермаркет игрушек, поэтому вы должны ответственно подходить к тому, что и как использовать. Никто не станет сдвигать рассчитанные ETA, чтобы вы могли узнать, а так ли продуктивен Go в действительности. Никто не будет мириться со штрафами от клиентов, пока вы проверяете, подходит ли Rust в качестве альтернативы языку программирования проекта (разве что вам поставили такую задачу, если это так – я очень за вас рад).

Вам нужно уметь работать в рамках и интересах проекта для его коммерческого успеха. Жажда знаний и страсть к новому пригодятся вам даже в таких условиях, просто старайтесь разграничить личную заинтересованность в разработке и требования заказчиков.

Тезисы

■ Разработчики любят код и новизну.

■ Не играйте с кодом на работе.

■ Разделяйте личный интерес и требования проекта.

Задание

Пофантазируйте. Представьте, что ваш текущий проект – «песочница» и здесь можно пробовать любые технологии и языки. Черт, да вы можете использовать по языку на каждый имеющийся у вас сервис! Подумайте, насколько сложно было бы совместить разные подходы к разработке, архитектуре, инструментам в одном проекте. Попробуйте оценить, насколько бы затянулась по времени реализация одной из ваших задач, если бы для этого использовался другой язык программирования.

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

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

Ошибки

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

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

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

А пока старайтесь регулярно задавать себе вопросы: насколько вероятно, что данная ошибка произойдет? Какие последствия она будет иметь для продукта и пользователя?

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

Старайтесь подходить к обработке ошибок прагматично, исходя из их потенциальной угрозы; не используйте больше контроля, чем необходимо. Возможно, это прозвучит не совсем логично, но вы ХОТИТЕ, чтобы определенные ошибки случались. Система без ошибок невозможна, и некоторые из них помогут вам лучше понять, с какими проблемами столкнулся продукт. Когда ошибки случаются, старайтесь собрать по ним всю доступную информацию, какую только можете получить (логи, stack traces, дампы данных), но, опять же, не пишите в лог каждое действие. В лучшем случае это просто оставит терабайтные файлы логов, в худшем – будет мешать работе пользователей или замедлять ваш продукт.

Тезисы

■ Не бывает кода без ошибок.

■ Используйте системы контроля ошибок с умом.

■ Относитесь к ошибкам прагматично, некоторые из них вам нужны.

■ Спрашивайте себя: как эта ошибка может случиться? Какой вред она причинит продукту и пользователю?

Задание

Проанализируйте код вашего проекта, узнайте, каким образом вы контролируете потенциальные ошибки.