В каждой команде есть коллега, чьи задачи после тестирования возвращаются с багами заметно чаще, чем у других. И есть его противоположность - разработчик, чей код почти всегда проходит проверку QA с первого раза. Возникает соблазн сразу сделать вывод: второй пишет код качественнее, а первому не хватает внимательности или опыта. Но что, если эта картина обманчива?

Представьте двух разработчиков - Александра и Бориса. Они работают над смежными модулями и регулярно проводят код-ревью задач друг друга. Статистика тестирования говорит сама за себя: у Бориса задачи практически без багов, а Александр время от времени получает тикеты на доработку. Руководитель уже начинает присматриваться к Александру, а Бориса ставят в пример. Однако реальная причина кроется не в том, кто пишет код, а в том, как его проверяют до передачи тестировщикам.

Александр подходит к ревью дотошно. Он не просто просматривает изменения, а мысленно прогоняет граничные сценарии, проверяет обработку ошибок и задумывается, как новый код поведёт себя в нестандартных условиях. Это заметно даже по времени, которое уделено ревью. Именно поэтому его правки к пул-реквестам Бориса часто вскрывают скрытые проблемы: здесь не обработается null, там упадёт при пустом ответе от сервера, тут забыли про таймаут. Александр отлавливает большинство багов Бориса ещё на этапе ревью, не давая им добраться до тестирования.

Борис же делает ревью иначе. Он проверяет код на соответствие стилю, смотрит, нет ли явных опечаток, и, если всё компилируется, ставит аппрув. Углублённого анализа логики, поиска крайних случаев, отслеживания обратной совместимости и потенциальных утечек памяти в его подходе нет. В результате все незамеченные дефекты в коде Александра беспрепятственно уходят на стол тестировщикам, где и превращаются в те самые “частые возвраты”.

Так и возникает статистическая иллюзия: Борис выглядит “звездой” не потому, что пишет идеально, а потому что его несовершенства гасит мощный фильтр ревью Александра. Качество же исходного кода у обоих может быть сопоставимым, а иногда Александр в принципе допускает меньше ошибок “на единицу написанного”, но его тщательность оборачивается против него - он не получает такого же уровня проверки в ответ.

Вывод. Прежде чем делать кадровые выводы по проценту возвратов из тестирования, взгляните на процесс код-ревью. Возможно, у “проблемного” разработчика просто нет качественного второго барьера в лице ревьюера. Улучшение культуры рецензирования в команде часто даёт больший прирост качества, чем попытки “подтянуть” одного человека. Настоящая сила - в симметричной, глубокой проверке кода, а не в иллюзии личной безупречности. Работая в разных ролях в разных командах я это понимаю, потому что был и руководителем и исполнителем. А тем руководителям, которые далеки от разработки, будет полезно ознакомиться с моимы мыслями на этот счет.