Дана стаття покликана викликати інтерес до цього питання та надихнути на детальніше дослідження. Якщо хтось вирішить закопатися глибше у цю тему, вищезгадані книжки будуть у нагоді

Кляте глобальне потепління!

Дублікація завжди краще некоректній абстракції, тому що потребує набагато менш ментального ресурсу на розвиток та підтримку.

Я думаю, у цьому й є ментальна проблема — щоб люди не подумали, раз ти дублюєш, то це 100% ознака дурості. Саме тому мав за мету розвіяти цей міф у статті

якщо людина новачок, то буває навпаки, вона робить абстрактні речи (тому що синдром самозванця, чи щось таке), та потім це важко розуміти розширювати та підтримувати.

дуже прикро буває, коли решта команди ігнорують рев’ю та мерджать такі ПРи 😢

погоджуюсь
а потім, коли приходить час рефакторингу, треба тиждень, щоб декомпозувати того монстра на 2-4 простих зрозумілих методи. Тож повністю підтримую ідею дублювання на самому початку 👍
А ще просто феєрія, коли треба змінювати того монстра, деякі його дублюють з перевантаженням з різницею у 1-2 if’и.

Тому я постійно просуваю ідею періодичного виділення хоча б одного розробника, скажімо, на 0.5-1 спринт кожні пару місяців тупо щоб рефакторити. На жаль, це рідко коли спрацьовує, бо нові фічі приносять дохід, а рефакторинг — ні 😥 (хоча насправді він теж, але у довгостроковій перспективі)

ну, в мене було трохи по-іншому: дві команди працювали над різними задачами, тому таких срачів, як у вас, не було. Зате через це нам не складно було доводити, що винні не ми 🤭
В решті решт, від тої команди таки позбавились, а ми красавчики у очах замовника 😁

ох, у мене прям флешбеки від роботи декількох команд над одним проєктом — у кожної свій лід, які між собою сруться; стан холодної війни, коли кожен тихенько перероблює проєкт під себе. А коли щось ламається, то наче потрапляєш в одну з п’єс Подерев’янського.
Так, щоб була команда від замовника не працював, але здогадуюсь яка там Санта-Барбара((

У моїй практиці таке рішення час від часу працювало по-різному: якщо на проєкті майже ніхто не вигорів та є хоч один педант, то якість рев’ю значно покращується. А от якщо вигоряння досить велике серед команди, то апруви ставляться майже не дивлячись. При чому іноді доходить до того, що люди ображаються, коли вказуєш на помилки...

Мені здається, у випадках, як ви описали, було б круто мати окрему команду з контролю якості коду. Часто не вистачає третьої сторони, яка б вказала на помилки, які бачиш кожного дня та через це відчуваєш толерантність до них.
До того ж, потенційно до такого відділу краще б прислухався бізнес, бо далеко не всі менеджери чи замовники повністю усвідомлюють проблеми технічного боргу й сприймають його як належне.

я колись бачив абстракції для моделей MVC, аж мурахи по спині пішли 😆

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