О чем вы думаете, когда думаете о качестве кода?

Это последовательность? Обеспечить соблюдение набора стандартов и передовых практик в вашем коде с помощью правил линтера и средств форматирования? Как насчет того, чтобы в вашем коде были тесты, которые запускаются автоматически в процессе сборки? А как насчет запросов на вытягивание и обзоров кода - защиты вашей основной ветки от прямых коммитов и проверки вашего кода коллегами?

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

Мы не можем все автоматизировать

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

Соответствует ли код установленным шаблонам? Использует ли он существующие модули или дублирует код? Все ли названо разумно? Находится ли код в нужном месте в кодовой базе? Будет ли это изменение иметь более широкие, непреднамеренные последствия? Действительно ли этот код адресует / решает то, что он намеревается сделать? Это вообще работает?

Автоматизированные процессы не могут ответить за вас (пока). Если вы (или другое человеческое существо) не задаете эти вопросы по своему коду, вероятно, вы не отправляете код качества. Вот почему у нас есть обзоры кода.

Хорошая проверка кода должна быть больше, чем просто код

Конечно, обзор кода должен касаться кода (в конце концов, он прямо в названии). Но это также должно касаться более широких вопросов, поставленных выше, а также конечного продукта.

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

Пять минут, дело сделано. Мне нравится.

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

Я предлагаю, чтобы хороший обзор кода должен включать как минимум:

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

Если есть какие-либо проблемы с любым из этих шагов, запрос на вытягивание должен быть отклонен. Не пройти иди. Не собирайте 200 долларов. Не сливаться с мастером.

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

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

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

Дважды проверьте свою работу на полноту

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

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

  • Пропущенные требования.
  • Отсутствующие тестовые случаи.
  • Лишний, неиспользованный или черновой код.
  • Недостаточно комментариев к коду.
  • Визуальные ошибки в некоторых браузерах / устройствах.

Если что-то из этого верно в отношении вашего кода, значит, ваш код не завершен. Если что-то из этого попадает в главную ветку, значит, вы ухудшили качество кодовой базы.

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

Двойная проверка полноты - важный первый шаг к качеству кода. Это самый простой шаг, но его также легче всего игнорировать.

Открывать пул-реквест следует только в том случае, если вы уверены, что ваш код завершен.

Проведите самостоятельную проверку своей ветки

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

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

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

Это также может избавить вас от некоторых затруднений. Я знаю, что это для меня.

Обеспечение качества кода должно быть неотъемлемым требованием каждой задачи разработки.

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

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

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

Если мы, как разработчики, не изменим то, как мы думаем о качестве кода, мы не можем ожидать этого от кого-либо еще.

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

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

Спасибо за прочтение!