Методика разработки через feature branches или pull requests позволяет организовать максимально независимую работу разработчиков – без необходимости частой синхронизации между ними. Большим плюсом этой методики является простота участия всех членов проектной команды в процессе code review, так как каждая новая feature, исправленный дефект, или доставка версии представлены отдельными ветками в репозитории исходного кода. Желательно, чтобы любое вносимое в ПО изменение происходило через создание отдельной ветки и включение ее (после code review) в основной стрим (обычно, ветка master).
Если на проекте используется trunk-based workflow (при котором разработчики работают с одной и той же веткой), то для организация эффективного code review процесса нетривиальна. Отсутствие запрета на прямое внесение изменений (push) в основные ветки разработки (develop, master) приводит к злоупотреблению “hot-fix”-ами для срочного решения проблем и, следовательно, не позволяет выстроить правильную deploy-rollback стратегию.
Стоит ли использовать pull request-ы даже если “работаю на проекте один”?
Однозначно, да. Это позволяет:
- привлекать людей “не с проекта” для code review. Программист понимает – одна голова хорошо, а две головы
мутантлучше. Требуйте у своего менеджера напарника для review; - группировать изменения по “фичам” или дефектам. Да, все слышали про ветки, но работать с ними не так удобно как с pull request-ами;
- получать преимущества от интеграции с CI сервером, который будет помечать pull request-ы статусом сборки;
- даже если кажется, что pull request-ы никто не смотрит, на самом деле это не так, только не надо “мержить сразу после создания” – так иногда делают и это действительно cargo cult.
Процесс code review направлен не только на улучшение качества кода проекта, но и на развитие коммуникации внутри команды, повышение технического уровня команды разработки. Если в процессе code review один из членов команды высказал замечание либо задал вопрос – он обязательно должен быть рассмотрен. В противном случае мотивация человека задающего вопросы быстро угаснет и польза от такого code review сойдет на нет. Если по какому-либо замечанию в процессе ревью возник спор/дискуссия – стоит убедиться, что команда пришла к единому конечному мнению.
А мы привыкли обсуждать замечания к коду устно, нам “так удобнее”.
Отвыкайте пожалуйста… Навыки письменной коммуникации, особенно на английском языке, ничуть не менее важны для разработчика, чем его техническая “крутость”. Только общаясь, преодолевая трудности “как же это ему объяснить без тыкания в код” можно прокачать письменный soft skill. Что касается взгляда со стороны (аудиторы частенько смотрят) – что можно сказать о проекте, где на 1000 pull request-ов было в среднем 0.13 комментариев per pull? Не думаю, что “там идеальный код и комментировать было решительно нечего”.
Важно, чтобы все разработчики из команды принимали участие в процессе code review. Это важно, так как code review предназначен не только для нахождения проблем в коде, но и для повышения квалификации разработчиков, которые принимают в нем участие, для поддержания общей ответственности за код (чтобы каждый разработчик из команды был знаком со всей кодовой базой, а не только со “своим модулем”), для развития внутри командного общения и повышения культуры разработки. Таким образом – мнение каждого члена команды, вне зависимости от его квалификации должно трактоваться с одинаковой важностью.
Применяемое в настоящий момент для всех новых репозиториев правило такое – все члены проектной группы, имеющие доступ в bitbucket, добавляются в default reviewer-ы. Они будут автоматически добавлены в pull при создании, без необходимости их выбирать вручную. Для merge-а необходимо наличие половины approve-ов (если команда состоит из 6 человек, то потребуется 3 апрува) и ни одного needs work-а. Если на вашем проекте не так – обратитесь к техническому координатору, ко мне, да хоть к CTO – мы обязательно поможем.