Любая команда разработчиков, стремящаяся создать высококачественное программное обеспечение, должна поощрять коллегиальные проверки кода. Рецензирование партнерского кода предлагает множество преимуществ для всех вовлеченных сторон:
- Проверяемый разработчик получает отзыв
- Рецензент получает более широкое представление о кодовой базе и функциях программного обеспечения.
- Банальные баги и недочеты выявляются ранее
- Общая структура кода и стандарты лучше поддерживаются
- Члены команды устанавливают взаимопонимание
За прошедшие годы наша команда составила список того, на что следует обращать внимание при проверке кода. Они сводятся к четырем вопросам, которые мы задаем себе.
Это код:
- Функциональный
- Доступный
- Надежный
- Проверяемый
Если вы еще не заметили, это означает ПЕРДЬ. Аббревиатура была не преднамеренной, и я не пытался изменить ее на что-то более элегантное. Как бы странно это ни звучало, этот фреймворк сразу же укореняется в умах разработчиков, как только они о нем узнают.
Код Функционален?
Код написан для выполнения требований. При просмотре фрагмента кода рецензент должен спросить:
- Делает ли код то, для чего он предназначен?
- Соответствует ли код всем критериям приемлемости, предписанным менеджером по продукту?
- Появится ли в коде очевидные проблемы регрессии, препятствующие работе других функций продукта?
- Если код связан с пользовательским интерфейсом, разработчик должен предоставить скриншоты. Соответствует ли пользовательский интерфейс макетам дизайна? Отзывчивый пользовательский интерфейс? Существуют ли очевидные проблемы со стилем, препятствующие кросс-браузерной совместимости?
Доступен ли код?
Это показатель того, насколько легко код может быть понят разработчикам, которые его не писали. Запутанный и чрезмерно сложный код сложно расширять и поддерживать.
- Запросы на вытягивание не должны быть слишком длинными
- Файлы не должны быть слишком длинными - более 150 строк, вероятно, слишком длинные
- Переменные и функции должны иметь соответствующие имена - используйте существительные для переменных и глаголы для функций.
- Есть ли правильное разделение проблем?
- Код не должен быть слишком сложным. Есть ли более простой способ достичь той же цели? Если рецензенту нужно потратить более 5 минут, чтобы выяснить, что делает функция, то это, вероятно, слишком сложно.
- Код должен соответствовать стандарту команды. Это включает в себя логическую структуру, файловую структуру и общий стиль кодирования.
- Правильно ли прокомментирован нетривиальный код?
- Правильно ли задокументированы API и уникальная бизнес-логика?
Надежен ли код?
Под надежным кодом понимается код, который выдерживает испытание временем. Надежный код масштабируемый, совместимый и достаточно производительный. Хотя может оказаться невозможным выявить все проблемы с надежностью посредством анализа кода, многие проблемы можно выявить заранее, просто применив некоторый здравый смысл.
- Код должен масштабироваться, чтобы соответствовать большой нагрузке и большому количеству пользователей (если применимо).
- Если возможно, код должен работать достаточно быстро.
- Если возможно, код не должен чрезмерно загружать память и вычислительные ресурсы.
- Код не должен приводить к утечкам памяти
- При работе с конфиденциальными данными код должен соответствовать стандартам безопасности.
- Код должен соответствовать применимым отраслевым стандартам (например, WCAG, HIPPA, PCI и многим другим). Выдержит ли он аудит?
Можно ли тестировать код?
Это относится конкретно к модульному тестированию. Хотя не каждая строка кода нуждается в модульном тестировании, мы должны стремиться тестировать критически важную бизнес-логику в качестве приоритета.
- Действительно ли тесты значимы? Действительно ли они проверяют код на соответствие требованиям?
- Хорошо ли разработаны тесты? Проверяют ли они соответствующие «счастливые» и «исключительные» сценарии?
- Охват тестирования должен соответствовать уровню, согласованному командой.
- Модульные тесты также необходимо поддерживать. Доступны ли они, как и остальная часть кодовой базы?
Если ваш код функциональный, доступный, надежный и тестируемый (FART), то это хороший код.