Инспекция кода — это неотъемлемая часть процесса разработки, придуманная для снижения технических недоработок и обеспечения постоянства кодовой базы. Все, кто пишет код, допускают ошибки. Поэтому крайне важно отловить эти ошибки до выхода рабочей версии и возникновения ошибок.
Гарантом обеспечения предельно простой и эффективной инспекции кода является создание чек-листа, в который попадет все, что кажется вам важным для надежности кода. В чек-лист можно включить соответствие лучшим практикам, правильность форматирования кода, актуальность проводимых тестов и версий, а также реализация вашей командой правил и политик написания кода. При использовании чек-листов у вас и команды появится кодифицированная отметка о качестве кода, что упросит и конкретизирует процесс инспекции.
Не существует какого-то единого стандарта для чек-листов. У каждого разработчика свои требования к коду, поэтому, пожалуйста, не относитесь к данной статье, как к единственно верному руководству. Мы писали ее только для того, чтобы показать вам, что именно мы считаем важными составляющими чек-листов. Используйте эти критерии при создании собственного списка.
Отправная точка
Для начала определитесь с главными элементами чек-листа. В первую очередь проверьте реализацию кода и убедитесь в том, что свои задачи он выполняет лаконично и эффективно. Если вам кажется, что существует более короткое решение, или же реализация выглядит не столь эффективной, то внесите нужные правки до того, как пойдете дальше по списку.
Удаляйте ненужный код, которым пользовались в прошлых версиях и сборках. Так вы получите «чистую» базу кода, понятную для команды, а заодно ускорите процесс отладки.
Стоит также подумать об анализе общей производительности кода. Например, есть ли библиотеки, которыми можно заменить функции или улучшить код? А, может, найдутся другие решения, способные сократить количество дополнительных функций? Проверьте, не остался ли код с фазы отладки (например, логи или старые функции) и удалите его — так вы максимально ускорите код.
Дублирование кода
Эта проблема куда более частая, чем кажется. Поищите копии кода, выполняющие одно и то же в разных функциях. При наличии дублей, создайте для них собственный метод. Данное решение подходит только для двух экземпляров. Поэтому если один и тот же код с аналогичными функциями повторяется в пяти разных файлах, то стоит преобразовать его в единую и унифицированную функцию.
Оформление
Код должен быть не просто эффективным, но и понятным для других — так, чтобы новый разработчик с легкостью разобрался в назначении каждой строки кода. Возможно, в дальнейшем ваш код потребуется изменить, удалить или провести рефакторинг. Читабельность и понятность важны для того, чтобы разработчик мог работать с кодом, не задавая вам лишних вопросов.
Ряд вопросов, которые необходимо задать себе при форматировании кода:
- Насколько осмыслены имена переменных?
- Есть ли в коде комментарии, разъясняющие сложные функции?
- Есть ли в коде длинные методы с многочисленными ответвлениями, которые можно вынести в более простой метод?
- Соблюдаете ли вы установленные в группе правила отступов и табуляции, правильно ли вы пользуетесь пробелами?
Безопасность
Безопасность в разработке программ должна стоять на первом месте. Это особенно важно при работе с личной информацией или сторонними библиотеками/утилитами. Если пользователь делится конфиденциальной информацией (например, паролями), то она должна шифроваться и проходить все нужные проверки. Кроме того, API-ключи, сеансовые идентификаторы и средства авторизации должны реализовываться в безопасном режиме. Если пользуетесь OAuth, то обязательно следуйте его стандарту.
Тестирование
По мере разрастания кодовой базы, тестирование (особенно нагрузки и производительности) становится все более значимой процедурой для проверки функциональности и предельной эффективности кода. Попробуйте провести тестирование с непрерывной интеграцией и удостоверьтесь в том, что эти тесты пройдены. Подумайте, нужно ли добавлять в текущие средства тестирования дополнительную проверку, и действительно ли они проверяют всю кодовую базу. Проверяют ли модульные тесты нужные функции? Охватывает ли тестовый фреймворк все потенциальные примеры использования?
Важность ревизии
Правила оформление кода внутри команды могут периодически меняться, поэтому чек-лист должен подстраиваться под эти изменения. Не забывайте дорабатывать чек-лист по мере разрастания кода и наработки опыта для предельного охвата всех областей кода. Если вы реализовали новую процедуру линтинга или добавили процесс тестирования, то включите их проверку в чек-лист.
Планирование и создание собственного метода инспекции кода занимает много времени. Ваше время крайне ценно, поэтому инспекцию кода можно отдавать на аутсорсинг. Так вы будете меньше беспокоиться о качестве кода, и получите больше времени на написание кода и поставку продукта — от этого выиграет и команда, и компания!
Надеемся, данный чек-лист помог вам лучше разобраться в процессе инспекции кода. Но помните, что этот список не является универсальным. И последний совет: не забывайте дорабатывать чек-лист под свои нужды. Успехов в разработке!
Перевод статьи James Gallagher: Writing an Amazing Code Review Checklist
