Идет война народная. CMS или фреймворки

Поговорим о вечном. Некоторые понимают этот вопрос как на Битриксе или на не-Битриксе, подразумевая другую CMS. Причина такого категоричного деления понятная — вряд ли сегодня можно найти маркетолога, который бы не слышал про Битрикс. Поэтому выбор стоит между вот про эту штуку я слышал и ну и все остальное.

Если вас одолевает такая дилемма, то тут всё просто — выбирайте Битрикс. Он круче, чем любая бесплатная или платная коробка. Доложите немного деньжат на лицензию и пользуйтесь без печали. На эту тему написана куча статей, как самим Битриксом (поразительно, но факт), так и его многочисленными студиями-партнерами, мы тоже такую писали. Нам можно доверять, как сказали бы в рекламе банка.

Но сам вопрос на чем следует уточнить по-другому: на готовой CMS или без?. Казалось бы, очевидный ответ: понятное дело, на CMS, это быстрее, так удобнее управлять контентом, и вообще как это так — вообще без CMS? А теперь медленно нащупайте на носу розовые очки и потяните вперед и вверх. Чувствуете, как ушам становится легче — это с вас ниспадает прошлогодний роллтон.

Мы не собираемся громить Битрикс. Эта штука работает, отлично решает конкретные бизнес-задачи, а потому прекрасно себя продает. Но стоит понять, что Битрикс — это не только готовая админка и маркетплейс я сейчас буду устанавливать все модули!, но и некоторые проблемки. Как и любая CMS — эта штука строго форматная, заточенная под определенные проекты. И чем дальше ваши идеи выходят за такие рамки — тем больнее вам будет. Это дорога погнутых велосипедов и сломанных костылей, о друг мой.

Почему программист грустит

Не знаем ни одного программиста, кто бы открыто топил за Битрикс. Наоборот, время от времени разработчики выкатывают на Хабр очередной хейт-пост.

Зато в блогах веб-студий часто можно увидеть разные 69 причин, почему мы делаем сайты на Битриксе. Объяснение простое — саму CMS выгодно продавать, на ней удобно производить сайты на потоке. Фактически, Битрикс уже продал себя конечному потребителю CMS, так что продажнику студии остается только немножечко дожать.

Но когда потребность бизнеса смещается от сайт, как у N к более сервисной и глубокой истории — CMS перестают их удовлетворять. Появляются другие потребности — например, проработанный прототип и концепция становятся важнее быстрого запуска с готовой админкой из коробки. Возможность гибко адаптироваться к меняющимся правилам игры становится важнее богатого выбора подрядчиков — просто потому, что бизнес начинает поиски исполнителя, который один раз и на всю жизнь. Иными словами, ищет долгосрочного партнерства или вообще собирает собственную команду.

Это меняет и видение студий-разработчиков — они чаще начинают говорить о продуктовой модели взамен ранее популярной поточной.

И снова о разработчиках. Они — ядро любой студии, ее основной ресурс. Сложно поддерживать их заинтересованность работой, если ваши проекты — это только сайты на определенной CMS. Разработчикам хочется пощупать перспективные фреймворки и технологии, а не пытаться раз за разом соорудить из деталей сборной модели парусника Херсонес Энтерпрайз из Star Trek. Конфликт интересов — тоже драйвер, однако.

О подходах к разработке

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

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

Теперь о вопросе CMS. Многие вещи, которые работали в первом подходе, хуже работают во втором. Одна из них — использование CMS для разработки, их вытесняют более гибкие фреймворки. Разница примерно такая:

CMS (или коробка) — это множество готовых шаблонов, подключаемых модулей, уже написанная админ-панель и дашборд. Проще говоря, конструктор с высокой степенью свободы. Но при этом все еще конструктор. Когда разработчик пишет сайт под конкретную CMS, он обязан работать в рамках ограничений, которая та задает. Таким образом, CMS подходит для создания проектов с определенной функциональностью, под которую у коробки есть детальки. Всё, что выходит за рамки — дописывается с помощью костылей и смекалочки и не всегда работает оптимально.Примеры CMS: 1C-Битрикс, Joomla!, Magento, CS-Cart.

Фреймворк — это набор правил, регулирующих процесс разработки. При этом программист не ограничен набором деталей, как это происходит при работе с CMS. Приходится писать больше кода, а многие типовые вещи создавать с нуля — это замедляет процесс запуска. Однако если ваш проект предполагает многократные дописки и расширения функций, то лучше отказаться от CMS и выбрать фреймворк. Команда продукта будет полностью нести ответственность за качество итогового кода, не будет таких ситуаций, когда страница медленно грузится, потому что в типовом шаблоне вашей CMS код писал какой-то неандерталец, мы не можем это изменить.Примеры фреймворков: Laravel, Yii, Zend, Symfony.

Подытоживая — главные причины, по которым стоит выбрать фреймворк.

Когда фреймворк лучше CMS

Продукт требует гибкости. Работая с CMS, вы можете реализовать только типовые вещи. Конечно, реализовать можно всё и всегда, но чтобы быстро и с кодом, за который не было бы стыдно — вряд ли. Если ваш продукт — это эксперименты, инновации, нестандартные решения, то выбирайте фреймворк.

Производительность важна. Иногда успех бизнеса напрямую зависит от того, как работает его сайт или приложение — важна стабильность, скорость, способность выдерживать нагрузки. Доли секунды решают — меняется конверсия, а конверсия влияет на доход. Коробка всегда будет работать медленнее голого кода или связки код + фреймворк.

Чистота кода важна. CMS часто генерируют куски своего кода, а официальные модули пишутся разными разработчиками. Причем не всегда по одним стандартам кодирования. Это затрудняет дальнейшую поддержку такого кода — если вы решите нанять новых или дополнительных разработчиков, познаете боль.

Качество важнее скорости развертки. Можно говорить о том, что коробочное решение быстрее развернуть, ведь там уже почти все готово. Но фактически скорость развертки важна только на первом этапе (этапе первой жизнеспособной версии, MVP). После него нужно мыслить стратегически и думать о масштабируемости бизнеса.

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

Вы не хотите тратить много ресурсов на поиски кадров. Научиться программировать под любую коробку проще, чем под фреймворк — не нужно понимание процессов на более низких уровнях. Поэтому рынок коробочной разработки наводнен кадрами разного качества. Это само по себе не проблема — но вашему эйчару приходится больше фильтровать поток резюме, подбирать критерии, тратить время. А когда попробуете поискать человека на позицию разработчика на фреймворке — встретитесь с более компетентными и зрелыми людьми. Совпадение? Не думаем.

И еще несколько пунктов в пользу фреймворков.

Даже если у вас коробка — то часто это уже не коробка. Те, кто работал с 1С, знает — в каждой новой компании это совершенно разная программа. Со временем количество дописок продукта возрастает до критической точки: за ней первоначальную версию узнать практически невозможно. То же самое с сайтами: есть шанс, что Битрикс-программисту придется разбираться в вашем продукте с нуля — от Битрикса в процессе предыдущей разработки останется мало.

Уровень зашоренности и понимания технологий. Можно быть блестящим разработчиком в рамках одной CMS, но если человек с этого начал и занимается одним и тем же долгие годы — то ему будет сложно стать разработчиком-универсалом. Со временем он разучивается мыслить творчески, не следит за трендами в разработке, зачастую использует устаревшие подходы и антипаттерны. А продуктовая история — это про think outside the box.

Программисты под коробку не дешевле. Чтобы научиться программировать под конкретную CMS, нужно пропустить через себя кучу документации, разобраться с системой — потратить время. Это, плюс общий хайп вокруг CMS, задирают планку часового рейта такого программиста. Добавьте сюда и то, что нетривиальные задачи на CMS требуют нестандартных подходов, а времени на их разработку тратится значительно больше, чем при использовании фреймворка. Соответственно, если вы думаете, что а возьму-ка я коробку, поддержка будет дешевле, то это далеко не всегда так — классные спецы везде дорого стоят.

Мнение разработчика

Микрофон перехватывает Александр, наш технический директор, у него есть, что сказать:

Фреймворки вытесняют коробочные решения, это происходит по разным причинам.Одна из них — значительная деградация подходов, использованных при старте работы над коробкой, но уже устаревших в данный момент. Стремясь сохранить обратную совместимость, приемлемые сроки выпуска очередной версии, которая делает все, разработчики многих CMS коробки выдают инструмент, пользоваться которым нет ни малейшего желания.Еще одна причина — неискоренимая черта программистов задействовать наиболее совершенные, подходящие, доступные ему инструменты.Третья — сила технического прогресса, от воздействия которой выживают только сильнейшие. Бесспорно, это фреймворки.