Просмотр кода

Хотя непосредственное выявление проблем с качеством часто является основной целью^[2], просмотр кода обычно проводится для достижения комплекса целей:^[3][4]

• Повышение качества кода — улучшение внутреннего качества и сопровождаемости благодаря лучшей читаемости, последовательности и понятности для других разработчиков.
• Обнаружение дефектов — обеспечение качества по внешним критериям, включая корректность, а также выявление проблем с производительностью, уязвимостей и внедрённого вредоносного кода.
• Обучение и передача знаний — распространение информации о кодовой базе, способах решения задач и ожиданиях по качеству между рецензентами и автором.
• Повышение чувства коллективной ответственности — формирование ощущения общей собственности на код и сплочённости команды.
• Поиск лучших решений — генерация идей для новых и более эффективных решений не только для текущего кода, но и в целом.
• Соответствие стандартам QA и ISO/IEC — выполнение требований по обязательному просмотру кода в ряде сфер, включая системы управления воздушным движением и другие критически важные системы.

Существует несколько вариантов процесса просмотра кода, дополнительные типы описаны в стандарте IEEE 1028^[5].

• Управленческие обзоры
• Технические обзоры
• Инспекции
• Пошаговый разбор (walk-through)
• Аудиты

Первым подробно изученным и описанным видом просмотра кода стал процесс под названием «инспекция», предложенный Майклом Фейганом^[6]. Фейгановская инспекция — это формализованный процесс, включающий тщательное и поэтапное обсуждение с участием нескольких специалистов. При формальном просмотре кода разработчики собираются на серию встреч для построчного анализа, часто используя бумажные копии исходников. Исследования показывают, что такие инспекции крайне детальны и эффективны для выявления дефектов^[6].

На практике команды разработки чаще используют более лёгкие процессы, при которых обзор касается изменений, связанных с тикетом, пользовательской историей, коммитом или иной единицей работы^[7].^[2] Часто устанавливаются правила, интегрирующие просмотр в рабочий процесс (например, обязательная проверка всех тикетов, обычно через механизм pull request), исключая отдельное планирование для каждой задачи. Такой процесс называют регулярным просмотров кода на основе изменений^[1]. Существует множество вариаций этого подхода.

По данным исследования 2017 года, 90 % команд, применяющих просмотр кода, используют именно процесс, основанный на изменениях, а 60 % из них — регулярный просмотр на основе изменений^[2]. Крупные ИТ-компании, применяющие этот подход, включают Microsoft^[8], Google^[9], и Facebook.

Согласно исследованиям Каперса Джонса, основанным на анализе более 12 000 проектов, формальные инспекции выявляют 60–65 % скрытых дефектов, неформальные проверки — менее 50 %, а тестирование — около 30 %^[10].

Однако данные исследования, включённые в книгу Best Kept Secrets of Peer Code Review^[10], показывают, что «лёгкие» проверки находят столько же ошибок, сколько и формальные, но при этом быстрее и дешевле^[11].

Исследования показывают, что до 75 % замечаний в ходе просмотра кода относятся не к функциональности, а к развитию и поддерживаемости программного обеспечения^[12], что делает просмотр кода особенно полезным для компаний с длительным жизненным циклом продуктов^[13]. Менее 15 % дискуссий в процессе просмотра кода напрямую связаны с ошибками^[14].

Результативность просмотра кода зависит от скорости его проведения: наиболее эффективной считается скорость 200–400 строк кода в час^[15].

Анализ и проверка большего объёма кода в час (особенно при критических приложениях) приводят к высокому риску пропуска ошибок^[15][16].

Инструменты статического анализа кода помогают рецензентам автоматически выявлять известные уязвимости и паттерны ошибок, особенно при работе с большими объёмами кода^[17]. Согласно исследованию VDC Research (2012), 17,6 % инженеров, занятых разработкой встроенного ПО, уже используют автоматизированные инструменты для просмотра кода, а 23,7 % планируют их внедрение в течение двух лет^[18].