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

Меня зовут Андрей Ходырев, и в профессии я достаточно давно — с 2011 года. Сейчас моя должность — ведущий инженер по тестированию. В последнее время занимаюсь не только тестированием и автоматизацией, но и разработкой. Я наставник в Практикуме на курсе автоматизатор тестирования на Java с августа прошлого года и занимаюсь там процессом улучшения код-ревью. 

Почему код-ревью — это так важно

В Практикуме код-ревью — неотъемлемая часть процесса обучения. Ревьюер — это человек, у которого есть реальный коммерческий опыт, и он проводит ревью студенческих проектов, чтобы передать свои знания и best practices. 

В коммерческой разработке код-ревью — золотой стандарт. Распространённая практика код-ревью следующая: надо получить минимум два подтверждения. Одно — от члена команды, например тимлида или старшего коллеги, и ещё одно — от человека из другой смежной команды, которая следит за читаемостью кода. Обычно помогает коллега, разбирающийся в нужной предметной области. Его задача — подсказать, как из хорошего решения сделать лучшее. 

Есть вещи, которые не относятся к особенной предметной области или конкретному проекту. Например, как правильно оформлять Java-код. Это тоже влияет на оптимальность: можно использовать существующую библиотеку, а можно написать решение с нуля. Как правило, за такими вещами следит не коллега, а специальный человек в компании, который проверяет качество кода. Он следит за соблюдением стандартов написания и оформления кода — чтобы между командами использовались best practices. Проверяет соблюдение naming conventions — это принятые в компании правила обозначения имён переменных, типов, функций в исходном коде и документации.

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

Если разработчик мёрджит код в репозиторий, даже тесты, он обязательно должен пройти ревью. В этом отличие коммерческой разработки от написания кода для себя.

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

Как стать ревьюером

Проведение код-ревью — форма менторства, когда один человек передаёт опыт другому. Когда учишь кого-то дисциплине, поддерживаешь эту дисциплину в себе. 

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

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

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

Иногда эту роль отдают тому, кто много лет работает в компании и хорошо знает Java. А иногда процесс формализуют, предлагая пройти внутреннее обучение и сдать экзамен.

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

Правила хорошего фидбэка

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

Способность увидеть картину целиком. Мастерство ревьюера заключается в том, чтобы не придираться к деталям, видеть общую картину. Обратную связь лучше давать в целом про код — соответствует ли он стандартам компании.

Уважение к другим. Важно, в каком формате оставлять обратную связь. Сплошной критики быть не должно, вместо этого можно попросить оптимизировать решение. Например, предложить использовать другую библиотеку или функцию. Но нельзя заставить человека взять и переделать то, на что было потрачено время и усилия. Вместо формата предписаний всегда лучше использовать пожелания.

Я считаю, что не нужно подробно объяснять своё мнение в комментариях в ревью. Разработчик, который писал код, может прочитать краткий комментарий и запросить пояснения. В этом случае лучше созвониться и обсудить нюансы лично. Это может потребоваться в двух случаях: комментарий составлен непонятно или разработчик пока не сталкивался с предлагаемым решением и нужна помощь более опытного коллеги. Этот обмен информацией предпочтительнее выносить за пределы ревью.

В ревью не должно быть:

• слишком резких формулировок;

• излишних требований;

• неоднозначных или непонятных советов;

• негативных / деструктивных эмоций;

• безапелляционных предписаний; 

• абстрактных комментариев, не связанных с конкретным куском кода.

Как реагировать на код-ревью

Не воспринимать слишком лично. «Твой код не оптимален» — прочитав такое, многие начинают винить себя, а не свою работу. Важно отделять личность человека от того, что он делает.

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

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