Как senior-программисты пишут код на самом деле

На YouTube-канале про IT Healthy Software Developer вышло новое видео, в котором автор рассказывает, как senior инженеры-программисты пишут код на самом деле.

Вот, о чём идёт речь в ролике:

1. Плохо, когда приходится просить менеджера проекта добавить новую пользовательскую историю для документации, это может привести к микроменеджменту.
2. Хорошо написанный код позволяет другим разработчикам легче его понять, что отличает junior разработчика от senior.
3. Написание качественного кода сокращает время на поддержку и объяснение кода другим, уменьшая количество перерывов в работе.
4. Код, написанный на уровне senior-разработчика, снижает вероятность его переписывания другими и увеличивает ‘срок жизни’ кода.
5. Важно завершать работу над кодом до перехода к следующему заданию, чтобы не накапливать технический долг.
6. Соблюдение стандартов кодирования и использование автоформатирования улучшают читаемость и согласованность кода.
7. Документирование используемых паттернов облегчает работу команды и поддержку проекта.
8. При внедрении новых паттернов важно обсудить их с командой и получить обратную связь перед полномасштабным использованием.
9. Не следует создавать отдельные задачи для рефакторинга, чтобы избежать их исключения менеджментом, рефакторинг должен быть инкрементным.
10. При оценке работы необходимо учитывать дополнительное время на неожиданные встречи по дизайну и написание документации.

Ниже представлен транскрибированный перевод видео на русский язык.

Почему вообще важно писать хороший код как senior

Ну, во-первых, это позволяет другим людям понять наш код. Вероятно, вы оказывались в кодовой базе, читая её и просто думали: “Я не понимаю, что здесь вообще происходит”.

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

Вторая причина, почему важно писать хороший код, заключается в том, что это сокращает время, необходимое для его поддержки и объяснения кому-то еще. Я часто работаю с другими разработчиками, которые торопятся и не следуют некоторым из шести вещей, о которых я собираюсь рассказать в конце видео, и потом они раздражены, когда их постоянно прерывают другие разработчики с вопросами о коде, и они говорят: “У меня нет на это времени”.

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

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

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

Как писать код как настоящий senior

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

На многих проектах огромное давление, особенно если вы используете скрам или что-то в этом роде, сказать, что вы закончили работу и знать, что, хорошо, я на 85% готов, но осталась небольшая часть кода, и я просто оставлю это на будущее время, я вернусь и исправлю, но по крайней мере, по моему опыту после многих проектов, когда я это делаю, я фактически накапливаю технический долг для себя.

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

Чем просто лгать им и говорить, что я закончил что-то. Таким образом, иметь самодисциплину действительно смотреть на свой код, как на свой личный бренд. Скотт Нимрод говорил об этом в первом интервью, которое я сделал с ним. Я думал, что это такой отличный момент, что каждый раз, когда мы пишем код, кто-то другой будет смотреть на него в будущем и, в основном, они будут оценивать нас исходя из этого кода.

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

К счастью, сегодня у нас есть такие возможности, которых не было 15 лет назад. Если вы используете VS Code или что-то подобное, знаете, что Emacs и Vim и некоторые другие инструменты тоже могут это делать. В большинстве языков есть автоформатирование, поэтому вы пишете свой код, если решите поставить переносы строк и фигурные скобки в разных местах, после сохранения файла он автоматически форматируется в одинаковом стиле.

Но если у вас нет чего-то подобного, то можно найти сторонний инструмент, если вы используете Visual Studio или тяжелую среду разработки с большим количеством функций. Для этого существуют плагины, которые позволяют выполнять форматирование кода и устанавливать его для вашей команды. Но одни из самых раздражающих кодовых баз, над которыми мне приходилось работать, были те, где у каждого был совершенно разный стандарт форматирования кода.

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

Используйте стандарты

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

Еще одна вещь, которая, я считаю, поможет вам писать действительно высококвалифицированный код, – это быть более дисциплинированным в документировании паттернов. Я вижу много команд, которые начинают новый программный проект. Они обсуждают среди себя, выбирают набор паттернов.

Некоторые из них просто открытые и очень известные паттерны, а некоторые – нет. Но особенно на проекте React или что-то подобное, где вы используете React только для рендеринга страницы, и есть множество других библиотек и различных паттернов, из которых можно выбирать. Иметь хотя бы одну тему вики или файл в формате Markdown, который говорит, вот все паттерны, на которые мы договорились использовать в проекте, я считаю, действительно ценно, потому что таким образом, если вы проводите код-ревью или что-то подобное, и вы обнаруживаете, что разработчик в вашей команде использует какой-то другой паттерн, это не просто произвольное решение, где вы говорите: “Мы выбрали этот паттерн, но не рассказали вам об этом”.

Вы можете сказать: “Эй, помните, когда вы присоединились к проекту, мы показали вам эту страницу со всеми паттернами, и этот мы не согласовали”. Если вы используете готовый паттерн, который уже является частью фреймворка или языка, который вы используете, я считаю, что очень хорошей идеей будет просто включить ссылку на документацию где-то онлайн, которая хотя бы имеет учебник или объясняет, как использовать этот паттерн, чтобы облегчить задачу вашей команде, чтобы им не приходилось искать пример, который может не соответствовать тому, что вы хотите, чтобы они рассматривали для уже существующего паттерна.

Теперь, если у вас есть новый паттерн, который вы создали, чтобы сделать код более сухим или, в общем, чтобы упростить его написание, я часто вижу, что люди представляют паттерн, проводят презентацию или собрание в Slack, и показывают его команде разработчиков, и это последний раз, когда они об этом говорят. Я считаю, что для каждого нового паттерна, для которого существует документация, необходимо создать тему вики или статью в формате Markdown или что-то подобное, которая говорит: “Вот цель этого паттерна. Вот когда его следует использовать. Вот когда не следует использовать.

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

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

Следите за обновлениями паттернов

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

Проводите постепенный рефакторинг

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

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

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

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

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

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

Выделяйте дополнительное время на задачи

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

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

И самое худшее – приходится вернуться к менеджеру проекта или скрам-мастеру и сказать: “Эй, мне нужно добавить новую пользовательскую историю для этого нового документа, который мне нужно написать.” Я имею в виду, вы почти гарантируете, что вас будут микроменеджить, если вы делаете такие вещи.

Поэтому я всегда говорю людям, давайте себе дополнительное время, не только для встреч и неопределенности, но и для написания документации.

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