С TBD, поскольку нет веток функций, это также означает отсутствие запросов на вытягивание. Вставьте сюда обеспокоенного старшего разработчика. Это не обязательно должно быть проблемой. Большинству команд просто нужен «принцип 4 глаз», который гласит, что по крайней мере 2 разработчика должны просмотреть и утвердить весь код, объединяемый в основную ветку.
Парное программирование — важный и очень ценный инструмент, но мне очень жаль, так как с этим заявлением я чувствую, что вы упускаете из виду ключевой момент проверки кода, который является ключевой частью процесса PR и действительно подрывает большинство других хороших моментов, которые вы делаете. в вашей статье. Мало того, что полезно получить отзыв от человека, который не участвовал в процессе написания рецензируемого кода, PR также обеспечивают видимость для остальной части команды выполняемой работы, что-то, что выходит за рамки весит много негативов, которые вы перечисляете с помощью ветвей функций. Вот почему важно создавать PR как можно раньше, часто задолго до того, как они будут готовы для рецензирования.
Точно так же я думаю, что ваша терминология немного необычна: многие рабочие процессы, использующие ветки функций, считают их эфемерными, и эти ветки функций должны быть как можно меньше. Я говорю эфемерный, а не «кратковременный», потому что, хотя в идеале функциональные ветки имеют короткое время жизни, это всего лишь побочный эффект хорошего процесса, а не существенное требование, поскольку оно зависит от того, сколько времени занимает проверка, сколько доработок или требуются изменения и т. д.
В соответствии с приведенным выше пунктом я подозреваю, что вы не имели большого опыта работы с проектами с открытым исходным кодом или не проводили много исследований о том, как они выполняются и поддерживаются, поскольку проекты с открытым исходным кодом продемонстрировали на большом размере выборки преимущества процесс PR по сравнению с гораздо меньшим размером выборки коммерческих проектов, над которыми вы лично работали и использовали в качестве основы для своего мнения по этому вопросу. Кроме того, совместная работа над крупными проектами с открытым исходным кодом на самом деле похожа на работу над крупными коммерческими проектами, где разные подразделения организации будут контролировать разные интегрированные системы или даже над одним и тем же проектом работают совершенно разные компании и подрядчики. Жаль, что вы, кажется, полностью пренебрегли изучением этого набора доказательств при формировании своего мнения о том, что является хорошей современной практикой разработки программного обеспечения.
