Почему я изменил свое отношение к качеству кода

1668031221 pochemu ya izmenil svoe otnoshenie k kachestvu koda

Джон Кобб

F19UjZTNIQOwYT-ZyMaq1PV0t3AKjd0oZI3a
80% кода, из которого состоит Матрица, – ненужное раздутие.

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

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

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

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

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

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

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

Хороший обзор кода должен быть не только кодом

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

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

Пять минут работа выполнена. Мне хорошо смотрится.

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

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

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

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

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

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

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

Еще раз проверьте свою работу на полноту

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

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

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

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

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

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

Вы должны открывать запрос на получение только тогда, когда вы уверены, что ваш код завершен.

Выполните самопроверку своего филиала

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *