"...один из старших программистов пытался и пытается продать идею, как офигенно делать контроллер с эндпоинтом на ~1к строк, где куча всего делается и поиск багов из прода там превращался просто в треш (+ куча внешних сервисов используемых в этом коде), причем на полной серьезе, типо так читаемость классная. Тыкать в IDE особо не надо, сразу идешь по потоку программы. Поэтому и интерфейсы в топку, иначе тыкнул по интерфейсу в коде и не сразу попал на класс реализации, очень неудобно ему. Очень яркие ощущения были от работы с его кодом."

Ну какая-то логика удобства в этом подходе прослеживается :) Когда я пишу код, который точно буду использовать только сам, иногда так для удобства и делаю, потому что действительно просто удобно его читать (мне), а в редакторе можно схлопывать просто куски. Главное, что если в голове есть четкая модель, то вообще пофиг, как код организован. Точнее, я настраиваю его структуру конкретно под себя, под свой стиль, который может быть весьма странным со стороны.

И это собственно самая что ни на есть ключевая проблема программной инженерии: пишу ли я код только для себя, который удобно использовать здесь и сейчас, или же его потом будут годами дорабатывать другие люди, плохо знакомые с проектом. И это даже сеньорам очень трудно объяснить...

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

А крупные технологические компании -- это, по сути, зомби, поддерживаемые тысячами сотрудников, которым на самом деле наплевать на компанию, и их единственное спасение -- организация как можно более чётких процессов разработки и тотальное документирование в расчёте на лёгкую заменяемость кодовых обезьянок. Но это тоже мало где имеется :) Вот почему они в конечном итоге терпят крах, а стартапы становятся именно тем, с чем они изначально конкурировали...

=

...А по поводу самого подхода "контроллер с эндпоинтом на ~1к строк" вот что хочу сказать: а вдруг этот сеньор проходил мой трек по гомотопической теории типов? :)

Напомню, что сложные системы в HoTT естественно представляются как композиции путей, склеивание вдоль границ, факторизация через эквивалентности и т.д. И вот подход "один здоровенный контроллер" можно интерпретировать как попытку представить всю бизнес-логику как один длинный путь в огромном пространстве состояний без явного разбиения на подпространства и эквивалентности.

Есть некоторый огромный тип/пространство (все возможные состояния системы и внешних сервисов), и контроллер -- это одна длинная кривая от "начало запроса" до "ответ отдан". Она почти не имеет явных разбиений на сегменты, почти не факторизуется через подпространства/подтипы, и минимизирует "прыжки" между контекстами/модулями.

Дальше немного поясню, почему это субъективно выглядит очень "читабельно" и комфортно с точки зрения человека, сидящего "внутри" гомотопической модели, и спалю ряд фишек, так и быть, из моего грядущего гайда "Функциональные архитектуры".