При проверке кода часто возникает следующая ситуация: какие-то обыденные аспекты вроде форматирования или стиля исследуются очень тщательно, вокруг них ведутся бесконечные дискуссии, а важные аспекты (выполняет ли код те функции, для которых он предназначен, продуктивен ли он, там есть обратная совместимость с существующими клиентами и многое другое) уделяется гораздо меньше внимания.
Недавно я опубликовал в своем Твиттере маленькая иллюстрация , которая проливает свет на эту проблему и дает рекомендации о том, на каких аспектах следует сосредоточиться в первую очередь, называемая пирамидой проверки кода.
Его цель — помочь расставить приоритеты для компонентов проверки кода, которые имеют первостепенное значение (по крайней мере, на мой взгляд), а также указать, какие компоненты можно и нужно автоматизировать.
Некоторые читатели просили предоставить альтернативную постоянную ссылку, которой можно было бы поделиться; другие хотели получить изображение с высоким разрешением.
Поэтому я делаю репост на вашем сайте .
Вы также можете скачать изображение в формате SVG .
Внизу находятся аспекты, которые исправить в будущем будет труднее, вверху — те, которые исправить будет проще.
Лучше сосредоточить свои усилия на трех нижних уровнях.
Два верхних уровня подходят для автоматизации.
Уровни перечислены сверху вниз.
Стиль
Какие вопросы задавать:- Используется ли стиль форматирования, принятый для проекта?
- Соблюдаются ли соглашения об именах?
- Соответствует ли код принципу DRY (не повторяйся)?
- Достаточно ли «читабелен» код (с точки зрения длины методов и т. д.)?
Тесты
Какие вопросы задавать:- Вы успешно прошли все тесты?
- Была ли новая функциональность достаточно протестирована?
- Проверяются ли крайние случаи?
- Используется ли модульное тестирование, когда это возможно, и интеграционное тестирование, когда это необходимо?
- Предоставляется ли нефункциональное тестирование (например, производительности)?
Документация
Какие вопросы задавать:- Достаточно ли документации для новой функциональности?
- Имеются ли все соответствующие документы (README, документация по API, руководство пользователя, справочная документация и т. д.)?
- Все ли документы понятны – без опечаток и серьезных грамматических ошибок?
Семантика реализации
Какие вопросы задавать:- Соответствует ли семантика исходным требованиям?
- Есть ли ошибки в логике?
- Это слишком сложно?
- Как обстоят дела с надежностью (есть ли проблемы с конкуренцией, правильно ли налажена обработка ошибок)?
- Как проходит выступление?
- Как обстоят дела с безопасностью (в плане SQL-инъекций и других проблем)?
- Каково отслеживание (например, метрики, журналирование, трассировка)?
- Выполняют ли недавно добавленные зависимости свою работу? Лицензии у них в порядке?
Семантика API
Какие вопросы задавать:- Является ли размер API достаточным и в то же время не чрезмерным?
- Выполняется ли каждая операция одним способом, а не несколькими?
- Сохраняется ли последовательность и принцип «минимума сюрпризов»?
- Четко ли разделены внутренний и внешний API, не просачивается ли внутренний API во внешний?
- Есть ли какие-либо изменения, которые вызывают проблемы в частях приложения, ориентированных на пользователя (классы API, конфигурация, форматы журналов и т. д.)?
- Является ли API в целом полезным и не слишком ли узконаправленным?
Часто задаваемые вопросы
Почему пирамида? Нижние уровни должны составлять основу проверки кода и занимать большую часть времени, затрачиваемого на нее.Итак, это треугольник! Это только вам так кажется.
Это вид пирамиды сбоку.
Какие инструменты вы использовали при создании этого изображения? Экскалидро .
Теги: #Идеальный код #проверка кода #проверка кода
-
Как Подружиться С Ltree И Laravel
19 Oct, 24 -
Миллиард Пикселей Для Миллиарда Звезд
19 Oct, 24 -
Программа Рит-2008 Готова!
19 Oct, 24
