Зачем мне твой код смотреть?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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