После того, как написан код, оформлен МР, самое время делать решения. Хороший ли результат получилился, или нет.
Это делает сторонний человек.
От ревьюера требуется наличие определенных навыков, так как рабочий процесс подразумевает, что не всегда тот, кто делал задачу, разбирается на все 100%.
Для того, чтобы понять, всё ли хорошо, нужно привлечь к проверке стороннего человека. Еще лучше, если этот человек будет лучше разбираться в технологии.
К примеру, первый человек ничего не понимает в python и PyQT. Он конечно может написать что-то на нем. И решить даже задачу. Но, так как он в нем разбирается примерно как в балете, то могут быть глупые ошибки, которые он не увидит. Для этого, в задаче пишется, что от ревьюера требуется знание парсултанга python. И, к примеру, второй человек может стать ревьюером и высказать замечания, и комментарии, тем самым улучшив конечный результат. Почему второй изначально не делал эту задачу, связанную с python? Ситуации разные. Самая распространенная, то что у второго уже есть задачи, что необходимо выполнить.
Можно расценивать ревью, как процесс обмена опытом и знаниями. Это полезно.
Для того, чтобы стать ревьюером, надо просмотреть колонку "In Review", у которых нет ревьюера, и выбрать задачу исходя из своих навыков. Если желающих будет мало, то ревьюеры будут назначаться принудительно
От ревьера требуется следующее:
-
Открыть МР
-
Прочить описание задачи
-
Прочитать описание проделанной работы
-
Обратить внимание на раздел "How to test"
-
Вникнуть в проделанную работу
- Проверить соответствие use-case с документацией (если они есть)
- Проверить UI на наличие всех функций
- Проверить код на наличие проблем
- Другие возможные проверки
-
Если есть замечания, то отписать в комментарии к МР и уведомить о них автора МР
У многих могут быть вопросы, почему комментарии должны быть в МР. Это нужно для обеспечения прозрачности дискуссии. Беседа по МР внутри МР. Это будет полезно, чтобы сторонний человек (к примеру тот, кто будет мерджить), который захочет узнать, что обсуждалось в рамках данного МР (На пример, почему было сделано такое решение в документации), не искал информацию по крупицам в дискорде или телеграмме.Комментарии пишуться здесь
-
После того, как автор МР поправит все замечания, он сообщает ревьюеру что все подправлено. Если заменчаний нет, то ревьюер нажимает на кнопку "Merge Pull Request" (если больше одного коммита в ветке, то выбирает "Squash and Merge")
Стоит отметить, что это возможно, если у МР нет конфликтов. Если конфликты есть (смотрите про rebase), то ревьер пишет автору МР, что нужно делать rebase. Не делает его сам.
Обращу внимание, что main ветка, это то, что будет у всех остальных, это своеобразный релиз. Поэтому надо внимательно ревьюить. Но если что-то проскочит, какой-то баг, то не беда. Он будет чиниться в отдельных задачах. Это обычное дело -
После того, как МР был вмерджен, задача переносится в колонку "On Acceptance" (Если ревьюер не тот человек, что создавал задачу)
