Comments 9
Заметил, что в статье практика PR'ов в основном критикуется за "токсичность" и за времязатратность. Однако я считаю, что эта проблема возникает из попытки решить "проблему доверия" через PR
Важные решения должны быть согласованы с командой, код должен быть покрыт тестами, а код-стайл - проверяться линтером. Тогда не придется "токсить" в PR'ах в духе "а почему скобочка не там стоит?" или еще хуже "а что это ты вообще выкатываешь?". И PR соответственно будут приносить чистый профит - позволят точечно фиксить какие-нибудь косяки по невнимательности / незнании предметной области / прочих человеческих факторах
Ок, жалоба на ПР озвучена. Она странная, но допустим. А дальше что? Какие-то предложения будут?
Запрос на ревью должен быть в приоритете у проверяющего, тогда MR не будет долго мариноваться. Если ты не можешь прервать свой "поток", тогда тебе лучше не заниматься код-ревью.
Проверять код должен тот, кто ставил задачу, тогда не будет формальных код-ревью.
Ревьюер должен уходить от болезни "я бы сделал по-другому". Если нет чётких причин не принимать код, но хочется по-другому - прими MR и сделай по-другому.
Если ничего этого нет, тогда действительно лучше без код-ревью.
Проверять код должен тот, кто ставил задачу, тогда не будет формальных код-ревью.
Что если если задачи ставятся продакт/прожект менеджером? Этот человек прекрасно понимает нужды пользователей, куда и как развивать продукт и слушает программистов о рамках их возможностей. Но он совершенно не обязан уметь программировать и что-то там понимать в коде. В итоге, кому задачу поручили, сам уже разобьёт её на более мелкие подзадачи, которые можно сделать быстро и начнёт работать потихоньку. Кто должен ревьювить в таком случае PR для вот этой большой задачи?
Продукт-менеджер ставит продуктовые задачи, а её декомпозицию на задачи разработчиков осуществляет тимлид. Вот он и должен принимать MR. Если на одного человека оказывается много нагрузки, а в команде достаточно сеньоров, то обязанности можно делить и тогда каждый сеньор будет "тимлидом" для своей _продуктовой_ задачи. Главное тут чтобы тот, кто проверяет MR, был глубоко погружён в проблематику общей (продуктовой) задачи, это лекарство от формальных ревью. И обычно этот человек тот, кто осуществил декомпозицию.
Не раскрыта тема использования PR не для ревью. Я, например, использую PR даже на проектах где я один - так проще сгруппировать изменения, прогнать CI и даже селф ревью сделать
Заберите обратно свои пулл-реквесты