Как стать хорошим разработчиком?04.01.2017 16:22

Я знаю массу крутых разработчиков ПО. Это волшебники, способные преобразовать код. Они используют кучу функции из lodash, о которых многие даже не слышали, умеют разделять, объединять, управлять и фильтровать объекты всего одной строкой кода. Они Гарри Поттеры бэкенда — знают, как решить любую задачу безопасными, надежными и оптимизированными операциями. Они настоящие мастера фронтенда, которые всего несколькими строками кода воплощают самые заветные мечты штатных дизайнеров. Уверен, вы тоже с такими знакомы.

Но не всех из них действительно классные. И я не о технических навыках, нет. Они не всегда классные как коллеги и сотрудники компании. Но почему так получается?

Действительно классные разработчики пишут отличный, качественный код — и делают это не от раза к разу, а постоянно. Их код не преподносит сюрпризов, а ведет себя ожидаемо. К тому же такие разработчики умеют общаться с людьми.

И всё? Ну, не только. Компании хотят зарабатывать. И разработчикам они платят за пользу.

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

Технический долг — это плохо продуманный рабочий процесс, и он тормозит работу разработчиков.

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

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

Пишите нормальный код

Наверно, это проще всего понять и принять. Ключевое — «нормальный». Благодаря своему мудрому научному руководителю я научился важным вещам, пока изучал автоматическое управление:

Решение проблемы считается достаточным, если оно разрешает поставленную задачу на удовлетворительном уровне с оправданными затратами.

«На удовлетворительном уровне» — да, да, это и значит «нормально».

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

Собственно, «нормально» — это когда код:

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

Это означает, что зачастую можно перестать работать над задачей, если отвечаете «нет» на такие вопросы:

• изменение сделает код читабельнее?
• вероятная польза стоит потраченного времени?
• станет ли код быстрее или надежнее?
• уменьшиться ли технический долг или хотя бы не увеличится?
• действительно ли вносимое изменение что-нибудь улучшит?

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

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

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

Это не значит, что не надо развивать свои навыки — наоборот, к этому надо постоянно стремиться. Но действуйте с умом и не тратьте время на вещи, не имеющие никакой ценности.

Пишите код с ожидаемым поведением

«Ожидаемо» — в программировании означает надежно и ремонтопригодно. Чем опытнее становишься, чем больше работаешь с чужим кодом, тем большее значение придаешь этому аспекту.

Нет ничего более изматывающего, чем погружаться в старый код, чтобы исправить функцию, которая не работает всего у одного пользователя. В конце концов обнаруживаешь, что для кода нет проверки и выражение «что за …?!» намертво отпечатывается на лице.

Хотите убедиться, что остальные не будут использовать git blame и упоминать вас в злобных твитах вроде »@ник, ты м…к!»? Тогда просто ответьте «да» на следующие вопросы:

• Ваш код безопасен и выдает ожидаемый результат?
• При надобности код проходил автоматизированные тесты? Любой хороший тестировщик подтвердит, что почти в 95% случаев это необходимо.
• Вы протестировали код?
• Тестировщик его протестировал?
• Код легко читать и понимать?
• Код можно расширить? Это вытекает из принципа нормального кода.

Если всё хорошо, то компания скажет вам «спасибо», и по крайней мере два человека будут спать спокойно — вы и ваш начальник. Ответы на эти вопросы помогут не переделывать раз за разом одно и тоже, вместо того, чтобы решать более интересные задачи в сэкономленное время.

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

А что же насчет остального?

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

Но есть еще две очень важные вещи — соблюдение дедлайнов и эффективное общение.

Но об этом уже в другой раз.