Юрий!

Бюро использует разные технологии, как самописные, так и промышленные. Это касается не только фреймворков, но и частей системы. Например, в качестве поискового движка в Советах используется Сфинкс, а в Дизайн-собаке — собственный, основанный на ПХП-морфи. К тому же, в работе с клиентами бюро постоянно сталкивается c разными системами. Уже успели поработать с Дотнетом, Битриксом, Йии и Гугл-вебтулкитом.

В любом деле важно полезное действие. Как правило, полезное действие выражается через бизнес-задачу. Если у вас есть хорошая рабочая идея, которую надо представить в интернете, то ЦМС может быть правильным решением. Модульная ЦМС с магазином готовых дизайнов избавит вас от необходимости программировать вообще. Это достаточно дешёвый способ выйти на рынок и начать зарабатывать на идее. Накопив первичный капитал, поразмыслите, действительно ли стоит писать систему под себя.

Другое дело — фреймворки. Они используются для создания интернет-проектов, когда программирование функционала является бизнес-задачей. Но, как это не удивительно, большинство фреймворков очень далеки от бизнес-задач. Они решают искусственные проблемы, созданные одними программистами для других программистов. Вместо того, чтобы описывать понятные вещи типа веб-страницы, обработчика пользовательского ввода или данных, они оперируют совершенно непонятными сущностями типа эктив рекодр, кэш, ОРМ, персистенс лейер, модель, вью, контроллер.

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

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

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

Я не побоюсь сказать, что Модель-вид-контроллер — просто «форсированный мем». Использование МВЦ не даёт гарантии хорошего кода. Главное в любой системе — архитектура. Можно написать проект на голом ПХП, Си++ или используя «Симфони». Важно, чтобы вся работа команды подчинялась каким-либо соглашениям. Без них вместо продукта получится неуправляемый монстр Франкенштейна.

Иногда без так называемого «говнокода» не обойтись. Чтобы избежать пагубного влияния, нужно локализовать места его обитания. Можно просто решить, где он допустим, а где нет. Я совершенно спокойно отношусь к говнокоду, который генерирует страницы, но нетерпим к нему в машинном отделении: модулях, которые отвечают за работоспособность системы в целом. Страница может измениться несколько раз за месяц, при этом никак не повлияв на остальные, и порой просто нет смысла вылизывть внутренности. Пустая трата времени.

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

Все ЦМС и фреймворки — просто инструменты. Выбор зависит от задачи, навыков команды и доступного времени на разработку.