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

  • Проверяемый разработчик получает отзыв
  • Рецензент получает более широкое представление о кодовой базе и функциях программного обеспечения.
  • Банальные баги и недочеты выявляются ранее
  • Общая структура кода и стандарты лучше поддерживаются
  • Члены команды устанавливают взаимопонимание

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

Это код:

  • Функциональный
  • Доступный
  • Надежный
  • Проверяемый

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

Код Функционален?

Код написан для выполнения требований. При просмотре фрагмента кода рецензент должен спросить:

  • Делает ли код то, для чего он предназначен?
  • Соответствует ли код всем критериям приемлемости, предписанным менеджером по продукту?
  • Появится ли в коде очевидные проблемы регрессии, препятствующие работе других функций продукта?
  • Если код связан с пользовательским интерфейсом, разработчик должен предоставить скриншоты. Соответствует ли пользовательский интерфейс макетам дизайна? Отзывчивый пользовательский интерфейс? Существуют ли очевидные проблемы со стилем, препятствующие кросс-браузерной совместимости?

Доступен ли код?

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

  • Запросы на вытягивание не должны быть слишком длинными
  • Файлы не должны быть слишком длинными - более 150 строк, вероятно, слишком длинные
  • Переменные и функции должны иметь соответствующие имена - используйте существительные для переменных и глаголы для функций.
  • Есть ли правильное разделение проблем?
  • Код не должен быть слишком сложным. Есть ли более простой способ достичь той же цели? Если рецензенту нужно потратить более 5 минут, чтобы выяснить, что делает функция, то это, вероятно, слишком сложно.
  • Код должен соответствовать стандарту команды. Это включает в себя логическую структуру, файловую структуру и общий стиль кодирования.
  • Правильно ли прокомментирован нетривиальный код?
  • Правильно ли задокументированы API и уникальная бизнес-логика?

Надежен ли код?

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

  • Код должен масштабироваться, чтобы соответствовать большой нагрузке и большому количеству пользователей (если применимо).
  • Если возможно, код должен работать достаточно быстро.
  • Если возможно, код не должен чрезмерно загружать память и вычислительные ресурсы.
  • Код не должен приводить к утечкам памяти
  • При работе с конфиденциальными данными код должен соответствовать стандартам безопасности.
  • Код должен соответствовать применимым отраслевым стандартам (например, WCAG, HIPPA, PCI и многим другим). Выдержит ли он аудит?

Можно ли тестировать код?

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

  • Действительно ли тесты значимы? Действительно ли они проверяют код на соответствие требованиям?
  • Хорошо ли разработаны тесты? Проверяют ли они соответствующие «счастливые» и «исключительные» сценарии?
  • Охват тестирования должен соответствовать уровню, согласованному командой.
  • Модульные тесты также необходимо поддерживать. Доступны ли они, как и остальная часть кодовой базы?

Если ваш код функциональный, доступный, надежный и тестируемый (FART), то это хороший код.