В первой части статьи «Proven Code Review Best Practices» мы рассмотрели, какие подходы к ревью должны быть у авторов кода. Но создание хорошей культуры обратной связи это улица с двусторонним движением. Естественно, на эту культуру имеют большое влияние ревьюеры. В этой части статьи мы рассмотрим, каких подходов им следует придерживаться в ходе ревью кода. Также мы уделим внимание практикам, содействующим повышению производительности – эти практики будут полезны как авторам кода, так и ревьюерам.
Лучшие практики ревью для ревьюеров
Когда вас просят дать фидбэк по коду, вам оказывают честь. Поэтому нужно стараться предоставлять как можно более полезную обратную связь.
Проводя ревью, вы не только демонстрируете ваши знания и навыки, но и учите других разработчиков, а также вносите свой вклад в успех команды. Но нет ничего хуже, чем потратить время на ревью и не дать хороший фидбэк.
Фидбэк должен быть конструктивным и излагаться в уважительной форме
Ревью ставит автора кода в уязвимую позицию, это нужно учитывать. Ваша задача – дать конструктивную и полезную обратную связь, причем сделать это нужно уважительно.
Особенно это важно при использовании специальных инструментов. Обращайте внимание на свои слова. Задеть чьи-то чувства очень легко, а в письменной форме – и того легче. Часто из-за нехватки времени люди отвечают на скорую руку, и в результате их слова могут быть поняты превратно.
При необходимости подойдите к человеку и поговорите с ним лично
Инструменты для проведения ревью и чаты позволяют нам коммуницировать с коллегами асинхронно и без лишних усилий. Но в некоторых ситуациях все же будет лучше поговорить лицом к лицу или путем видео/аудио связи.
Сложные проблемы, например, решаются куда более эффективно, если вы просто подойдете к вашему коллеге или позвоните ему, чтобы обсудить все лично. То же касается дискуссионных вопросов или обсуждения чувствительных тем.
Если вы считаете, что ваши слова могут задеть чьи-то чувства или приведут к тому, что инженер «потеряет лицо», будет лучшей стратегией изложить свои замечания в электронном письме или в личной беседе. В общем, в сложных случаях тщательно обдумывайте ваши каналы связи.
Обеспечивайте отслеживаемость решений
Хотя личные встречи и видеосвязь положительно сказываются на динамике команды, ваши обсуждения нужно документировать. Особенно важна возможность отследить результаты ревью, чтобы впоследствии можно было на них ссылаться. В этом вам помогут специальные инструменты для проведения ревью.
Подобные инструменты это хорошие каналы связи для решения всех простых вопросов. Они позволяют всей команде следить за обсуждением, а также искать нужные решения и, в дальнейшем, разбираться в кодовой базе.
Всегда объясняйте, почему вы отклонили изменения
Будем честными. Отклонение изменений это не то, что порадует их автора. Поэтому важно объяснить свой отказ вежливо, конструктивно и дружелюбно.
Пояснение причин, стоящих за отказом, поможет автору кода не только учиться и расти, но и понять вашу точку зрения. Это также способствует продолжению диалога с автором.
Скажите автору кода, что конкретно он должен сделать, чтобы изменения были приняты.
Лучшие практики ревью кода для увеличения продуктивности
Самая большая сложность, с которой сталкиваются в ходе ревью и авторы кода, и ревьюеры, это ограниченность времени.
Ревьюеру сложно выкроить время на ревью кода коллег: для этого придется потеснить собственные задачи. Но если процесс ревью кода правильно организован, он может принести большую пользу команде.
Включите ревью кода в свой обычный распорядок дня
Структурируйте свой рабочий день таким образом, чтобы у вас оставалось время для ревью. Например, выделите на него один час, с 11 до 12 ежедневно.
Таким образом вы постоянно сможете находить время для ревью, причем об этом будете знать и вы, и ваша команда. Это время также пригодится вам в тех случаях, когда вам захочется проанализировать и оценить свою работу.
Уменьшайте количество переключений между задачами: они убивают продуктивность
Переключение с одной задачи на другую не проходит бесследно для вашей продуктивности. Зная, что ревью кода не прервет вашу текущую работу, вы сможете работать более сфокусированно.
Когда и сколько времени вы можете работать без прерываний, зависит от вашей загруженности, количества ревью, которые вам нужно сделать, а также от времени, когда обычно код поступает на ревью. Например, ваша команда может счесть разумным установить два временных промежутка, когда могут проводиться ревью – утром и перед уходом из офиса. Таким образом вашим коллегам не придется ждать фидбэка слишком долго.
Обратная связь должна быть своевременной
Не рекомендуется сразу же после получения уведомления бросаться делать ревью, поскольку переключение между задачами снижает продуктивность. Тем не менее, регулярность и своевременность проверок кода дает определенные преимущества и его авторам, и ревьюерам.
Как можно более быстрая обратная связь гарантирует, что работа автора кода не будет заблокирована на долгий период ожидания. К тому же, если автору приходится ожидать фидбэк слишком долго, ему становится сложнее вспомнить, какие изменения он вносил, и откорректировать свой код согласно полученным рекомендациям. Помните, что слишком долгое ожидание обратной связи это ловушка №1 в ревью кода.
Ревьюеру тоже есть смысл как можно быстрее взяться за ревью. Если вы один из первых проверяющих (особенно если таких людей достаточно много), вы ощущаете, что ваши усилия по просмотру кода не бесполезны, они имеют значение. А когда вы уже пятый человек, просматривающий этот код, вы заранее знаете, что вряд ли найдете там что-то новое. (Если такое происходит постоянно, следует подумать о снижении числа ревьюеров).
Лучше делать ревью чаще и понемногу
Исследования показывают, что фидбэк будет качественнее, если проводить ревью почаще и таким образом проверять меньшее количество изменений за раз. То есть, не нужно ждать, пока накопится несколько изменений, ожидающих проверки, а затем просматривать их все сразу. Лучше придерживаться своего обычного расписания и проводить по одному ревью за раз (или даже проверять только часть присланного кода, если изменения большие).
Если ваши обычные ревью слишком объемны и занимают очень много времени, авторам кода следует подумать о внедрении практики маленьких последовательных изменений.
Фокусируйтесь на главных проблемах, не придирайтесь к мелочам
Ваша цель как ревьюера – помочь с основными проблемами, такими как баги, проблемы архитектуры или структуры, вещи, ведущие к проблемам с поддерживаемостью.
Конечно, если видите опечатки, плохо названные переменные или проблемы стиля, можно на это указать. Но не это ваша основная задача. Кроме того, чрезмерное обсуждение мелких проблем не несет пользы для автора кода.
Используйте контрольные списки
Одна из лучших практик в ревью кода – использование системного подхода. Наличие контрольного списка может увеличить скорость и повысить производительность работы при проведении ревью. Вместо того чтобы создавать подобный список с нуля, скачайте готовый и подгоните его под правила вашей команды и ваши нужды. Для скачивания ищите контрольные списки, заточенные под ваш технологический стек.
