Как добиться успеха с Code Review
Обзоры кода — суперактуальная тема в наши дни, многие считают ее узким местом, а другие относятся к ней крайне серьезно. Поговорим о том, как преуспеть (всей команде, а не только вам) в этой сверхважной части процесса создания ПО.
Проблемы и как их исправить (или избежать)
Обычно, когда вы заканчиваете разработку какой-то новой функции и у вас есть готовый запрос на включение для проверки, возникают некоторые проблемы:
Никто не делает обзор
Да, это суперобычная вещь. Вы прикладываете все усилия, чтобы сделать все возможное, и никто не проверяет это.
Есть несколько вещей, которые вы могли бы улучшить:
- Вы неправильно уведомили людей: может быть, просто назначить кого-то через Github PR недостаточно? Отправьте ссылку в какой-нибудь канал Slack, чтобы привлечь внимание, или просто спросите кого-нибудь напрямую.
- Приятели по проверке кода. Да, просто заведите несколько приятелей по проверке кода (одного или нескольких), вы всегда сможете сверять PR друг с другом и работать очень быстро. Это своего рода компромисс для обзора друг друга.
- Внесите свой вклад. Помните, что часть этой игры заключается в том, что вам нужно оставлять комментарии, запрашивать изменения и одобрять PR других людей. Если вы помогаете другим людям улучшать их код, они будут помогать вам точно так же. (Или более вероятно, что они что-то прокомментируют и в итоге одобрят).
- Слишком много изменений. Одна из наиболее вероятных причин – слишком большой PR! Итак, старайтесь, чтобы ваши изменения были короткими и лаконичными, не сходите с ума по рефакторингу (мальчиковые скауты) и старайтесь разделить свою работу на большее количество пулл-реквестов. Может быть, эта часть разделения вашей работы может начаться на собраниях по планированию или уточнению вашей команды :).
Слишком много отзывов
А еще у нас обратная проблема. Вы размещаете сообщение о проверке кода в канале «Общие» в Slack, и вдруг у многих появляется время проверить ваш PR. Теперь у вас слишком много изменений и запросов на изменения, которые вы должны обязательно решить, чтобы вы могли объединить свои изменения.
- Начните просить только одного человека сделать обзор. Вы можете попробовать это с одним коллегой, который, как вы знаете, все проверит очень хорошо и которому вы доверяете. Сначала исправьте его комментарии, и тогда ваш PR будет более совершенным и с одним первоначальным одобрением. Затем более широко общайтесь с другими людьми, чтобы проверить это. На этом этапе люди должны оставлять только небольшие комментарии и одобрения.
- Товарищи по обзору кода (да, это тоже очень хорошо помогает предотвратить эту проблему).
- Исправьте все комментарии и попросите провести второй раунд одновременно: не просто исправляйте комментарии разработчиком, исправьте сначала все.
Технические дебаты по комментариям
Как правило, разработчики программного обеспечения любят время от времени устраивать технические дебаты. В целом, это хорошо и заставляет вас узнавать больше и определять некоторые новые технологии или технические концепции, о которых вы не знали в прошлом. Но проблема в том, что некоторые люди склонны делать это в Code Review.
Если у вас возникла эта проблема, а обсуждение каких-либо изменений слишком жарко или слишком затянулось, вы можете сделать следующее:
- Немедленно прекратите это: лично обратитесь к другому разработчику, чтобы обсудить комментарии. Иногда вам обоим требуется личное объяснение, чтобы полностью понять аргументы и предложения.
- Не принимайте это на свой счет: делайте это профессионально.
- Объясните себя, используя реальные и последовательные аргументы: например, шаблоны проектирования, архитектуру, рекомендации по стилю или даже предыдущий опыт. Старайтесь не ограничиваться только мнением.
- Сосредоточьтесь на предоставлении функции клиенту: Иногда кто-то предлагает другой подход для того же, сравните компромиссы обеих реализаций. Возможно, улучшение времени выполнения на 0,0001 мс не является необходимым, или, может быть, его предложение значительно улучшит удобство сопровождения вашего кода. Если время, затраченное на исправление, не так уж много, и это добавляет реальную ценность, улучшите его!
- Когда вы оба придете к соглашению, напишите заключение в ПР.
Хорошие вещи
Когда у вас хороший ритм работы, а ваши коллеги оставляют полезные комментарии, вы увидите в этом так много плюсов:
- Это снижает риск возникновения проблем с QA
- Предоставляйте качественные функции
- Вы многому учитесь у других разработчиков, а другие учатся у вас (передача знаний)
- Лучшая сплоченность в коллективе. Эта функция разрабатывается не только вами, она также включает в себя навыки ваших коллег, и успех этой функции распределяется между всей командой.
Вывод
Помните, что здесь важна командная работа. Обзоры кода не должны мешать вам или вашей команде, это хорошая возможность вместе делать отличные вещи и учиться друг у друга.
Если вы считаете, что мне нужно что-то добавить, просто дайте мне знать в комментариях, а также поделитесь своим опытом!
Надеюсь, вам понравилась эта статья, хорошего дня!
Гонсало П.
