Ревью кода — это довольно обыденный процесс. Хотя и немногие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом, сообразить пару причин, зачем же просматривать код коллег, довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.

Я расскажу про причину, зачем вам лично может быть полезно ревью кода сокомандников. С небольшим примером и исследованием.

Стандартные цели ревью кода

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

• Проверить отсутствие дыр в безопасности

• Убедиться в соответствии кода с требованиями

• Проверить архитектурные решения

• Проверить code-style

• Проверить возможные проблемы с производительностью

• Найти баги и ошибки

• Убедиться в легкости (хотя бы относительно :) ) будущих модификаций и поддержки

• Обмен знаниями

Почти все эти цели нацелены на решение багов и возможных проблем в будущем. То есть улучшаем качество кода, чтобы в будущем было меньше багов. Ну и лучше качество — более счастливые разработчики, а значит код легче читать и сопровождать :)

Отлично — смотрим код, чтобы качество кода было получше. Но зачем лично разработчику смотреть код, какая польза здесь и сейчас? В списке целей есть последний пункт "обмен знаниями". Обычно это означает обучение менее опытных разработчиков особенностям проекта и в целом написания кода. Но что насчет просто чтения?

Собственно, зачем?

Чтение кода позволяет быть более знакомым с кодом. А чем больше разработчик знаком с кодом, тем более он им доволен! Оказывается, то, как люди воспринимают "качество кода", определяется не только сложностью этого кода. Но и тем, как разработчики знакомы с кодом. Знакомство с кодом играет большую роль в восприятии кода.

Те, кто делают ревью чаще, обычно оценивают код как более "качественный", чем те, кто меньше делает ревью. У команды может быть несколько кодовых баз, которые похожи по качеству кода. Но люди будут воспринимать один код как "хороший", а другой как "плохой" просто на основе того, работали ли они с ним, или нет.

Пример и исследование

Можете посмотреть интересную историю о знакомости с кодом и его восприятии. Докладчик рассказывает историю про команду, у которой было несколько проектов. Код в одном проекте они называли "хорошим", а в другой "отстойным". Но после анализа сложности оказалось, что проекты очень похожи по качеству и сложности кода. То есть хорошим кодом оказался просто тот код, с которым эти разработчики работали. А плохим — код в малознакомом проекте, который им достался от другой команды.

Также есть исследование-опрос о ревью кода. В нем показывается, что разработчики, которые удовлетворены ревью кода (и делают его чаще), обычно более удовлетворены кодом их проекта. И наоборот, те, кто не удовлетворен процессом ревью кода, обычно оценивают код на проекте хуже.

Ревью кода полезно для тебя лично. И необязательно копать детали

Итак, причина читать код — это (как минимум) для того, чтобы отслеживать изменения и "индексировать" код у себя в голове. Совсем не обязательно сильно вдаваться в детали каждого пул реквеста, особенно когда проект гигантский. Но чтение хотя бы для понимания изменений и структуры кода поможет улучшить восприятие кодовой базы. В общем это хороший способ не грустить по поводу качества кода проекта :)