|
|
@@ -0,0 +1,36 @@
|
|
|
+# Что такое Code Review
|
|
|
+Code Review - это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.
|
|
|
+
|
|
|
+# Зачем нужен Code Review
|
|
|
+Code Review может являться частью процесса выполнения задачи (частью workflow). Может показаться, что ревьювить должен только тимлид или старший разработчик, но хорошей практикой является если в процессе ревью задач участвуют все разработчики. Таким образом можно не только распределить нагрузку от ревью, но и составить у команды более широкое представление о выполняемых задачах. Также это помогает делиться best practices внутри команды.
|
|
|
+
|
|
|
+# Положительные эффекты в команде от Code Review:
|
|
|
+
|
|
|
+* понижает bus factor: больше людей в команде в курсе выполняемой задачи, в случае необходимости внесения изменений в задачу как минимум два человека смогут это сделать. Задача больше не завязана на одного разработчика.
|
|
|
+
|
|
|
+* помогает найти и выявить баги и недоработки на этапе разработки задачи: так как задача сразу проверяется как минимум двумя разработчиками, это повышает вероятность нахождения упущенных кейсов, которые без код ревью могли бы попасть на бой.
|
|
|
+
|
|
|
+* повышается читаемость и качество кода и как следствие - его поддержка в будущем: код понятен не только одному человеку, а нескольким участниками команды, это упрощает и ускоряет разработку в будущем.
|
|
|
+
|
|
|
+* обучаемость сотрудников: разные реализации и подходы к решению задач могут заимствоваться участниками команды друг у друга во время код ревью
|
|
|
+
|
|
|
+* развитие и поддержание здоровой культуры в команде: участники команды учатся друг у друга и учатся давать качественную обратную связь, повышается взаимодействие внутри команды.
|
|
|
+
|
|
|
+# Минусы:
|
|
|
+
|
|
|
+* при разработке задачи на реализацию тратится чуть больше времени
|
|
|
+
|
|
|
+* в задаче задействованы как минимум два разработчика (тот, кто делал задачу и тот, кто ее ревьювил)
|
|
|
+* Когда не нужно проводить код-ревью?
|
|
|
+Системная практика оценки кода внутри команды — не всегда полезное с точки зрения затраты ресурсов решение. Оно отнимает время и у автора, и у проверяющего, а еще требует глубокого погружения в процессы и сил на коммуникацию.
|
|
|
+
|
|
|
+# Причины, чтобы отказаться от код-ревью в конкретном случае:
|
|
|
+
|
|
|
+* нет человека, который обладает экспертизой в области специфики задачи;
|
|
|
+* изменения слишком незначительны и не требуют проверки.
|
|
|
+# Причины, чтобы отказаться от постоянной практики код-ревью:
|
|
|
+
|
|
|
+* у всех разработчиков одинаковый уровень знаний, навыков и уровень погружения в контекст;
|
|
|
+* приняты другие практики проверки кода — например, парное программирование;
|
|
|
+% постоянные конфликты из-за код-ревью в команде;
|
|
|
+практика уже показала свою неэффективность.
|
