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

Что первым приходит в голову, когда вы думаете о качестве кода? Это согласованность? Или использование стандартов и лучших практик программирования? А что насчет авто-тестов или код-ревью?

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

Да, они все полезны, но решают только половину проблем.

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

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

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

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

Качественное код-ревью это больше, чем просто просмотр кода

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

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

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

Вот минимум, который нужен для качественного ревью кода:

· Стянуть ветку на свою локальную машину

· Сбилдить проект

· Проверить, что код работает без ошибок на всех основных браузерах или устройствах

· Проверить, что выполненная работа соответствует требованиям задачи

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

Выполнение этих маленьких шагов повысит качество вашего кода и уменьшит усилия на его просмотр.

Проверьте свою собственную работу дважды

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

· Неучтенные требования;

· Ненаписанные или неизмененные тесты;

· Избыточный, неиспользуемый или черновой код;

· Комментарии отсутствуют, либо устарели;

· Визуальные баги в некоторых браузерах / устройствах.

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

Главное: качество кода начинается с автора кода. Не ленитесь проверять свою работу дважды.

Проверьте свою ветку

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

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

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

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

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

Измените своё отношение к качеству кода внутри команды. Поймите, руководители проектов и владельцы программных продуктов обычно не обеспокоены качеством кода - у них есть свои собственные проблемы. Вся ответственность ложится на вас. Думаете ли вы о конечных потребителях? Или хотите поскорее выполнить работу, не прилагая особых усилий? Поддержание высокого качества кода не должно рассматриваться как нечто дополнительное. Это должно быть неотъемлемым требованием для каждой задачи. Пусть это документально нигде не закреплено. Сделайте это своим личным требованием к написанию кода.

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

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

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

Перевод статьи Why I changed the way I think about Code Quality от Digital Skynet :)