Заберите обратно свои пулл-реквесты

[@eeeeeeeeeeee]

Заметил, что в статье практика PR'ов в основном критикуется за "токсичность" и за времязатратность. Однако я считаю, что эта проблема возникает из попытки решить "проблему доверия" через PR

Важные решения должны быть согласованы с командой, код должен быть покрыт тестами, а код-стайл - проверяться линтером. Тогда не придется "токсить" в PR'ах в духе "а почему скобочка не там стоит?" или еще хуже "а что это ты вообще выкатываешь?". И PR соответственно будут приносить чистый профит - позволят точечно фиксить какие-нибудь косяки по невнимательности / незнании предметной области / прочих человеческих факторах

[@cupraer]

Но ведь и это не абы кто, это глыбы нашей индустрии, те самые атланты, на чьих плечах стоят Design Patterns, Agile, DDD, CI, CD, Clean Code, TDD, BDD […] выше цитаты Кента Бека, Дейва Фарли, Мартина Фаулера.

Глыбы нашей индустрии и атланты — это не пустозвоны и балаболы наподобие Мартина и Фаулера (кто такие эти Бек и Фарли, я, слава всевышнему, вообще не знаю). Рассказывать, как нужно писать код, не написав в своей жизни ни единой строчки полезного, красивого, рабочего и общедоступного кода — это типичное инфоцыганство, которое адекватные люди порицают.

Если нужно несколько имен, которые действительно являются глыбами индустрии — вот: Алан Кай, Джо Армстронг, Джон Хьюз, ладно, пусть даже Роб Пайк.

[@Getequ]

Ок, жалоба на ПР озвучена. Она странная, но допустим. А дальше что? Какие-то предложения будут?

[@cupraer]

Конечно. Вайбкодинг, тесты и проверка — одной и той же ллмкой.

[@monco83]

1. Запрос на ревью должен быть в приоритете у проверяющего, тогда MR не будет долго мариноваться. Если ты не можешь прервать свой "поток", тогда тебе лучше не заниматься код-ревью.

2. Проверять код должен тот, кто ставил задачу, тогда не будет формальных код-ревью.

3. Ревьюер должен уходить от болезни "я бы сделал по-другому". Если нет чётких причин не принимать код, но хочется по-другому - прими MR и сделай по-другому.
   
   Если ничего этого нет, тогда действительно лучше без код-ревью.

[@VMarkelov]

Проверять код должен тот, кто ставил задачу, тогда не будет формальных код-ревью.

Что если если задачи ставятся продакт/прожект менеджером? Этот человек прекрасно понимает нужды пользователей, куда и как развивать продукт и слушает программистов о рамках их возможностей. Но он совершенно не обязан уметь программировать и что-то там понимать в коде. В итоге, кому задачу поручили, сам уже разобьёт её на более мелкие подзадачи, которые можно сделать быстро и начнёт работать потихоньку. Кто должен ревьювить в таком случае PR для вот этой большой задачи?

[@Tishka17]

Не раскрыта тема использования PR не для ревью. Я, например, использую PR даже на проектах где я один - так проще сгруппировать изменения, прогнать CI и даже селф ревью сделать