Почему большой/объемный pull request это плохо (или хорошо)?

Question

[bpGusar]

Ситуация такая:
было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

Для меня такие большие ПР это проблема, я не понимаю как их ревьюить, они выглядят монструозно и не поддаются пониманию. И вот вопрос - как в этой ситуации быть? Стоит ли запрашивать ревью у разрабов из других команд когда происходит ревью в промежуточную ветку или же оставить этот ад как есть?

P.S Чем подробнее будет ответ тем лучше. Нужно разобраться в теме насколько можно. Спасибо )

Answer 1

[Станислав Макаров]

было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

Вам нужно решить, где чья ответственность. В большой команде не может каждый разработчик читать код каждого другого разработчика. Поэтому нужно просто делать адекватные коммиты/мелкие ПР и ревьюить их, а если они уже поревьюены - то не обращать на них внимания, т.к. это теперь не ваша ответственность.

Почему вы повторно ревьюите этот же код, ещё и теперь объединённый в один большой ПР? Какой смысл? У вас что-то не так с организацией ответственности.

Comments

[bpGusar]

У вас что-то не так с организацией ответственности.

мягко сказано... )) и не только в плане ПР/коммитов

[Станислав Макаров]

bpGusar так тогда в чём суть вашего вопроса? Гибкости Git и командных сервисов обычно хватает на любой workflow, ваша задача определиться с ним. Просто отдайте ответственность на того, кто ревьюит мелкие ПР, и не занимайтесь потом ревью большого ПР вообще в принципе. Ну или если там какие-то хотфиксы были на ходу (без "мелкого ПР"), смотрите только их.

Стоит ли запрашивать ревью у разрабов из других команд когда происходит ревью в промежуточную ветку или же оставить этот ад как есть?

Думаю это единственно возможный для вас вариант, если вы уже не справляетесь. Хотя, для начала подумайте, а зачем вам вообще разработчики из других команд. Оно им надо? Если надо, почему тогда это "другие команды"? Отдельная команда - она на то и отдельная, что может не знать 80-90% всего, что происходит внутри остальных команд. А чтобы не знать эти 80-90%, как раз и придуманы вещи вроде TypeScript с его типизацией и интерфейсами, вроде OpenAPI, Protocol Buffers/gRPC и прочих-прочих способов описания интерфейсов различной природы.

[Станислав Макаров]

bpGusar т.е. начал бы я с проверки того, что деление по командам у вас не для галочки

[bpGusar]

Станислав Макаров, make sense, спасибо

Answer 2

[Владимир Коротенко]

Размер имеет значение, иногда!
Ваша задача иметь пул реквест совпадающий с вашей задачей.
Если вы меняли ORM то это одно, а если добавляли розовую кнопку для входа то совсем другое.
В моей работе было и то и другое. 2х месячная работа скидывалась в основную ветку, потому что было надо.
И были мелочи потому что "вот все мы закончили этот юнит"

Придерживайтесь схемы когда любая операция в гите создает или исправляет какую то задачу

Answer 3

[uvelichitel]

не поддаются пониманию

кажется это главное требование к PR -- что бы поддавался пониманию.
А по трудозатратам, разве вам есть разница ревьювить один большой или 10 маленьких? То есть, может быть, неудобства обусловлены просто неравномерностью вашей загрузки. Месяц ждёте, потом надо отревьювить вчера... Тогда за это и топить -- за равномерное распределение нагрузки, сбалансированные бизнес-процессы, эффективное использование ресурсов бла-бла-бла.