Ревью кода 30.10.2016

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

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

Ревью кода с одной стороны дает представление о новых изменениях в системе членам команды, не принимавшим участие в непосредственном кодировании. С другой — участник ревью сам по себе может являться автором кода, в который вносятся изменения, а, следовательно, может обладать знаниями, необходимыми для оценки влияния изменений на работу системы. Это следует учитывать при выборе участников ревью. Если ревью кода всеми членами команды по каким то причинам сложно практиковать (например, их слишком много), то первым претендентом на участие в ревью должен стать человек, разбирающийся в подсистеме, изменения в которую вносятся.* Верно и обратное:

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

Очевидно, что мы не всегда обладаем достаточным временем на полное изучение кода (вспомним, что на детальный разбор кода объемом 200-300 строк в среднем тратится около 5 часов), поэтому прежде всего при ревью кода следует:

— оценить качество изменений с точки зрения архитектуры системы;
— оценить влияние изменений на функционал системы;
— исследовать код на предмет грубых ошибок;
— исследовать новый код на наличие уже изобретенных “велосипедов”.

Если в вашем проекте используется одна из практик разработки через тестирование (TDD/BDD), то ревью кода следует начать с тестов на новый код — так вы сразу ознакомитесь с новым функционалом и примерами его использования. Тесты сами по себе являются документацией к коду, поэтому если уже на этой стадии у вас возникнут вопросы, то ревью уже можно считать не пройденным.

Стоить помнить, что ревью кода — не инструмент для отслеживания code style — для этого существуют другие, специализированные инструменты. Обращать внимание на явные огрехи стиля конечно нужно, но не стоит этим злоупотреблять. Человек, отправивший вам на ревью значительный объем кода, ожидает от вас явно не этого.

Инструменты для ревью (например, Upsource от JetBrains) позволяют взглянуть на код свежим взглядом. И этим нужно пользоваться. Практика показывает, что само-ревью так же является очень эффективным инструментом. Осуществите ревью собственного кода и только потом приступайте к правкам. Такой подход не даст вам схалтурить.

*Некоторые инструменты для ревью кода способны вычислить таких претендентов автоматически, но если такого софта у вас нет, система контроля версий вам в помощь.

by 30.10.2016