Инженеры и эксперты говорят, что проверка кода (code review) редко выявляет ошибки — её настоящая задача состоит в том, чтобы помечать код, который трудно поддерживать в дальнейшем, сообщает портал The New Stack.

Рецензирование программного кода — это систематическая процедура обеспечения качества, в которой участвуют коллеги разработчика. Она предполагает тщательную проверку кода, когда разработчик отправляет запрос на изменение или слияние.

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

По словам старшего инженера-программиста Марка Доминуса, хотя многие компании, очевидно, проводят проверку кода, они не «четко формулируют, каким должен быть результат проверки», и это проблема. «Представьте, что вы начинающий инженер, и вам впервые поручают провести проверку кода. Каков должен быть результат вашей работы? Во многих местах, где я работал, этому вопросу не хватало четкости», — отмечает он.

В своем посте на Mastodon на эту тему Доминус пишет, что «любой, кто полагается на проверку кода для поиска ошибок, живет в мире иллюзий», главным образом потому, что в целом невозможно найти ошибки, просто изучая код. Он подчеркивает, что основная цель проверки кода — найти код, который будет сложно поддерживать в будущем.

Верный путь к плохим результатам проверки кода

Доминус отмечает, что в сценариях, когда от инженера-программиста ожидают неспешный просмотр изменений и указания на то, что ему не нравится, это приводит к плохим результатам, то есть побуждает людей пытаться навязывать свои собственные предпочтения относительно того, как все должно быть сделано, и тогда обычно возникают споры.

«Иногда начальник дает младшему инженеру малоинформативное задание, например: „Попробуй найти какие-нибудь ошибки“, и это ставит джуниора в неприятное положение, — поясняет Доминус. — Может быть, он и найдет ошибку, отлично! Но что, если нет? Найти ошибки, просто изучив набор изменений, крайне сложно и требует определенной доли удачи».

Он предлагает другой подход, при котором проектные тимлиды дают примерно такие указания: «Изучайте код два часа, записывайте все, что вам непонятно, и если вы не дочитали до конца, отметьте, где остановились».

Путь к получению реальной ценности

«Если рецензенту не хватит времени просмотреть всё, это уже ценный результат: изменения слишком велики или сложны, чтобы их можно было понять за два часа. Возможно, набор изменений следует разбить на два или более вариантов поменьше, которые следует рассматривать отдельно. Тогда независимо от того, насколько неопытен, некомпетентен или страдает от похмелья рецензент, он сможет выполнить поставленную задачу, и то, что он сделает, будет иметь реальную инженерную ценность», — объясняет Доминус.

В данном случае реальная инженерная ценность — это отрицательный результат. Команда выявила код, который другой член команды не может понять, или набор изменений слишком громоздкий для текущего процесса проверки кода... или и то, и другое.

Проверка кода — это скорее театральное представление

Согласный в целом с этими утверждениями, Михаил Голиков, инженер по обеспечению качества в компании, занимающейся высоконагруженными платформами электронной коммерции, говорит, что «проверка кода — это своего рода театр», если команда полагается на неё для выявления ошибок.

«Человек, бегло просматривающий diff, не может увидеть состояние гонки или скидку, которая становится отрицательной под нагрузкой. Проверка предназначена для выявления кода, который вы будете ненавидеть поддерживать позже; тесты — для кода, который не работает сейчас, — подчеркивает он. — Рецензент читает чистый diff, видит осмысленные имена и аккуратные функции и нажимает „одобрить“. Но ничто из этого не говорит вам о том, что ключевая часть приложения неисправна и предоставляет пользователю неработоспособный сервис».

Голиков, который также является мейнтейнером Open Source-инструментов тестирования Python, объясняет, что ошибки, вызывающие сбои, находятся не в коде, который могут прочитать разработчики. Они возникают в состояниях, в которых код находится во время выполнения.

Не испытывайте чувство удовлетворения, не получив каких-либо доказательств

«Когда команда рассматривает проверку как фильтр ошибок, она выпускает проект с чувством удовлетворения и без каких-либо доказательств, а затем обнаруживает ошибки в продакшене, — отмечает Голиков. — Проверка кода предназначена для того, чтобы задавать вопросы типа: „Буду ли я ненавидеть поддерживать это через шесть месяцев?“ и „Действительно ли это работает?“, когда тест проводится на реальных входных данных, а не для того, чтобы человек бегло просматривал запрос на слияние под конец рабочего дня».

Среди разработчиков и поставщиков практически нет споров о том, что процессы проверки кода нуждаются в изменениях, особенно в эпоху ИИ с растущим распространением агентных инструментов кодирования.

Джуда Тауб, управляющий партнер Hetz Ventures, согласен с этим мнением и отмечает, что на протяжении многих лет инженерные команды рассматривали проверку кода как последнюю линию защиты от ошибок, но это никогда не было ее сильной стороной.

«Проверка кода выявляет стиль, архитектуру, читаемость и удобство сопровождения, — говорит он. — Тесты выявляют ошибки. В производственной среде обнаруживается все остальное. Лучшие инженерные организации не полагаются на то, что другой разработчик обнаружит едва заметный крайний случай, скрытый в сотнях строк кода — они создают системы, которые автоматически проверяют корректность задолго до того, как запрос на слияние попадет к другому человеку. Проверка кода призвана обеспечить бесшовную работу над кодом следующего инженера».

Будущее проверки кода

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

«Роль инженера продолжает смещаться от самого кодирования к проверке архитектуры, намерений и бизнес-логики. В будущем даже это может быть автоматизировано», — предсказывает он.

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

Совокупные революции нативных облачных технологий, платформенной инженерии и переходящего в агентное кодирование вайб-кодинга (можно добавить большие данные, DevOps и стандартизацию в сторону корпоративного Open Source, если хотите) изменили способ работы разработчиков ПО. Поэтому, очевидно, должны произойти и соответствующие изменения в способах проверки кода.