Свeтлaнa Шaпoвaлoвa, кoммeрчeский aвтoр и пeрeвoдчик, пeрeвeлa стaтью Kamil Wysocki o тoм, кaк стaть xoрoшим рaзрaбoтчикoм и чтo для этoгo нужнo.
Я знaю мaссу крутыx рaзрaбoтчикoв ПO. Этo вoлшeбники, спoсoбныe преобразовать код. Они используют кучу функции из lodash, о которых многие даже не слышали, умеют разделять, объединять, управлять и фильтровать объекты всего одной строкой кода. Они Гарри Поттеры бэкенда — знают, как решить любую задачу безопасными, надежными и оптимизированными операциями. Они настоящие мастера фронтенда, которые всего несколькими строками кода воплощают самые заветные мечты штатных дизайнеров. Уверен, вы тоже с такими знакомы.
Но не всех из них действительно классные. И я не о технических навыках, нет. Они не всегда классные как коллеги и сотрудники компании. Но почему так получается?
Действительно классные разработчики пишут отличный, качественный код — и делают это не от раза к разу, а постоянно. Их код не преподносит сюрпризов, а ведет себя ожидаемо. К тому же такие разработчики умеют общаться с людьми.
И всё? Ну, не только. Компании хотят зарабатывать. И разработчикам они платят за пользу.
Что может быть полезным? функция, которая привлекает новых пользователей;
оптимизация, которая экономит деньги;
улучшение, уменьшающее технический долг. Эту долгосрочную пользу, к сожалению, часто игнорируют.
Технический долг — это плохо продуманный рабочий процесс, и он тормозит работу разработчиков.
В эту пользу разработчики инвестируют свое время, которое идет не только на решение поставленных задач, о нет! Им приходится держать баланс между программированием, общением, личностным развитием и прочими делами.
Как убедиться, что вы хороши не только в технических умениях, но и действительно держите баланс и приносите пользу? Вернемся к моему определению и разобьем его на части. Сфокусируемся на двух наиболее важных и необходимых достоинствах отличного разработчика.
Пишите нормальный код
Наверно, это проще всего понять и принять. Ключевое — «нормальный». Благодаря своему мудрому научному руководителю я научился важным вещам, пока изучал автоматическое управление:
Решение проблемы считается достаточным, если оно разрешает поставленную задачу на удовлетворительном уровне с оправданными затратами.
«На удовлетворительном уровне» — да, да, это и значит «нормально».
Как это относится к разработке ПО? Представьте, что вы разработали доказательство концепции метода преобразования случайных величин. Есть некие условия, планы и правки. Сейчас вы очищаете код, объединяя условия. Тем не менее, есть ощущение, что код можно еще улучшить. Может, объединить еще какие-нибудь условия? Или использовать стрелочную функцию и избавится от дурацкого возврата? Немного упростил, ну да ладно.
Собственно, «нормально» — это когда код:
- читабелен и понятен другим людям;
- хорошо написан: структурирован, расширяем, отвечает универсальным правилам программирования и стилю самой компании;
- эффективен и надежен.
Это означает, что зачастую можно перестать работать над задачей, если отвечаете «нет» на такие вопросы:
- изменение сделает код читабельнее?
- вероятная польза стоит потраченного времени?
- станет ли код быстрее или надежнее?
- уменьшиться ли технический долг или хотя бы не увеличится?
- действительно ли вносимое изменение что-нибудь улучшит?
Если сложно отвечать самому, то обратитесь к коллегам. Это хорошая привычка — просить проверить код старшего разработчика, техлида или технического директора. Причем не так важно как они это сделают: просто взглянув на экран или отправив код на рецензирование.
Разрабатывая нормальный код, вы даете своей компании понять, что получаемая зарплата превращается в достойный и полезный труд, а не в бесчисленные часы шлифования кода до уровня поэмы. Компания — не открытый GitHub-проект, который можно улучшать годами. Помните об этом — и все будут довольны.
Можно быть крутейшим программистом, однако трата огромного количества времени в попытках довести всякую работу до совершенства не принесет ничего в профессиональной жизни.
Это не значит, что не надо развивать свои навыки — наоборот, к этому надо постоянно стремиться. Но действуйте с умом и не тратьте время на вещи, не имеющие никакой ценности.
Пишите код с ожидаемым поведением
«Ожидаемо» — в программировании означает надежно и ремонтопригодно. Чем опытнее становишься, чем больше работаешь с чужим кодом, тем большее значение придаешь этому аспекту.
Нет ничего более изматывающего, чем погружаться в старый код, чтобы исправить функцию, которая не работает всего у одного пользователя. В конце концов обнаруживаешь, что для кода нет проверки и выражение «что за …?!» намертво отпечатывается на лице.
Хотите убедиться, что остальные не будут использовать git blame и упоминать вас в злобных твитах вроде »@ник, ты м…к!»? Тогда просто ответьте «да» на следующие вопросы:
- Ваш код безопасен и выдает ожидаемый результат?
- При надобности код проходил автоматизированные тесты? Любой хороший тестировщик подтвердит, что почти в 95% случаев это необходимо.
- Вы протестировали код?
- Тестировщик его протестировал?
- Код легко читать и понимать?
- Код можно расширить? Это вытекает из принципа нормального кода.
Если всё хорошо, то компания скажет вам «спасибо», и по крайней мере два человека будут спать спокойно — вы и ваш начальник. Ответы на эти вопросы помогут не переделывать раз за разом одно и тоже, вместо того, чтобы решать более интересные задачи в сэкономленное время.
Ответы на эти вопросы также помогут контролировать технический долг. В итоге компания будет точно знать, что вашей работе можно доверять, и кому-нибудь другому не придется исправлять ваши ошибки и править код, как это делали и вы, и я неоднократно. И, поверьте мне, это очень большая ценность.
А что же насчет остального?
Мы рассмотрели всего два аспекта работы разработчика, которые действительно очень важны. Для начала необходимо убедиться, что нет проблем с кодом — он нормальный и ожидаемый, именно это — основа вашей работы.
Но есть еще две очень важные вещи — соблюдение дедлайнов и эффективное общение.
Но об этом уже в другой раз.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
