Ну не знаю, мне кажется скорее нет, чем да. Джуны, мидлы и сениоры люди разного "назначения". Содержать команду исключительно из высококлассных программистов слишком дорого, тут важна грань. Джуну что простенький класс дадут реализовать по контракту, что функцию, только контракт будет на словах или в комментариях. Какая разница? Важно что ни там ни тут его не допустят до архитектурных вопросов.

Нет, я согласен с тем, что на процедурке (или мульти) можно добиться хорошо читаемой системы, потратив определенное время. Вся загвоздка в том, что на живом проекте, чтобы оставаться в good shape потребуется значительный overhead. Иначе перерастет в нагромождение и тогда потребуется еще больше ресурсов для мейнтейна. Вот она главная мысль в чем кроется. Здесь же и экономические критерии, или как ты их называешь "менеджерские заморочки", вроде как-то так.

По поводу моих критериев, ты слишком уж изолированно их рассматриваешь. Да, вероятно у битрикса большое сообщество, только люди от него плюются и бегут при упоминании в вакансиях. Разве такое есть с тем же Symfony?

ООП удобно! Само по себе понятие оцениевается субъективно, каждому свое. Большая и до сих пор нарастающая распространенность заставляет задуматься, если такому дикому количеству людей удобно, а мне нет, может быть дело во мне? =)

P.s. Шутка, да? Ну выходит не понял, слишком уж часто звучали фанатики и пропавшие программисты совершенно в нешуточной форме.

Ты пропустил слово "монолитный". Большой монолитный проект. Тут я не спорю, и даже наоборот, считаю это самым большим минусом ООП. Уж очень велик соблазн сделать красивую многофункциональную систему, которая будет легко патчится. На деле обычно получается не так.

Я не про сами библиотеки говорю, а про архитектуру "сборка библиотек". Это минимум инфраструктуры, это антипод монолитной архитектуры, где инфраструктура стоит во главе угла.

Нет, не начинается. Кстати, начиналась один раз, когда работал тот парень, который ушел. Вот тогда действительно началось, до сих пор икается.

У меня другой косяк - повторы кода. Это смертный грех в ООП, жуткий антипаттерн. Я знаю, однако многолетний опыт показывает, что не такой уж он смертный. Этот антипаттерн спасает от наслоений и связанности. Пусть даже за счет потери скорости начальной разработки. В условиях, когда проект давно работает, она собственно и не важна, эта скорость. Гораздо важнее текущие изменения. А тут дискретность и модульность важнее. Плюс к этому - та самая мультипарадигма. Можно применять любые методологии, которые наиболее отвечают поставленным задачам. Потому что не нужно оглядываться на всю систему в целом.

По большому счету основа бизнеслогики, это данные. Связь между частями системы в основном идет не на уровне инфраструктуры, а на уровне СУБД. И потому можно легко и просто разграничить ответственноси - раз, использовать разные парадигмы - два.

Да, код зачастую дублируется в разных модулях. Но его и править проще, он имеет влияние только на небольшой, определенный участок. Это и считается библиотеками. А то общее, что используется в них, называется сервисы или хэлперы. Они пишутся по возможности универсально. Но не в привязке к системе, а самодостаточно (я про тот же DIP).

Я не знаю, как там в битриксе. И если честно, нет желания смотреть. Ты там на ролик ссыль дал, я посмотрю потом. Просто я твой коммент увидел:

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

Конечно, если у тебя интернет магазин, то там менять особо нечего. Магазины не меняют принципов веками, так маленько. Товар - продавец - покупатель. Но есть и другие сферы, где требования меняются часто и кардинально.

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

Так пусть твоя команда разделяет твои взгляды (это хорошо), но предвзятость твоя от этого не уменьшается. Вы все равно повязаны одним проектом. Ну или методикой разработки проектов, если это студия. А есть и другие мнения и другие оценки.

Ну и битрикс может сам не справился. Зачем ты его выставил образцом мультипарадигмы?

Да я особо не вникал, потом пару моментов напишу, что глаз резануло. А где она, ExampleCMS?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.