Целесообразность использования коробочных CMS. «ЗА» и «ПРОТИВ».

Разработка → Целесообразность использования коробочных CMS. «ЗА» и «ПРОТИВ».

Наша студия уже давно прослыла своим «коробконенавистничеством». Поэтому, объективности ради, стоит сказать, что использование коробочных CMS в веб-разработке имеет место быть, даже с моей точки зрения, но только в ряде очень лимитированных случаев.

Когда имеет смысл использовать коробочную CMS. Несколько безапелляционных «ЗА».

1. Для максимально типовых задач (форум, обычная блоголента на том же вордпрессе, небольшой корпоративный сайт со стандартным набором модулей и функционалом заложенным в сборку CMS).
2. При невысоких требованиях к команде по разработке – интеграция КМС должна сводиться к натягиванию шаблонов на готовые модули (с этим часто даже студенты неплохо справляются)
3. При практически полном отсутствии кастомных / уникальных задач в рамках всего проекта – не более 5-10% от всего объема задач.
4. При сжатых сроках разработки (1-2 недели) с минимальной претензией на индивидуальность и уникальность решений. По сути это называется так – пользуйся тем что заложено в сборку и не выё*******. Иначе говоря, или пользуйся тем что есть в плагинах\стандартных модулях КМС или погибни в коде, пытаясь переписать пол-ядра этой самой CMS, если задача не решается типовыми модулями CMS.

Когда нет имеет смысла использовать коробочную CMS. Несколько безапеляционых «ПРОТИВ».

1. Если кастомная часть вашего проекта превышает хотя бы 25% от всех задач – в этом случае коробочная CMS становится нецелесообразна к использованию т.к. написание кастомной части под ее архитектуру будет медленее, а значит и дороже  (+ еще и работать будет хуже, из за коробочной архитектуры, чем решение, сделанное на каком-нибудь профессиональном фреймворке - symfony, zend).
2. Если ваша задача разработать highload проект (готовая КМС крайне ресурсопрожорлива из за своей универсальности) или веб-стартап. Подобные проекты по пишутся под индивидуальную механику и логику – в подобных проектах 80% кастомного и 20% типового поэтому любая готовая коробка просто бесмыссленна.  80-90% бюджета занимает то, что придется писать с нуля.  
3. Если есть потребность в замене части готовой системы – часто это вообще или невозможно или почти нецелесообразно – придется написать сначала новый фреймворк и потом переписать под него еще и CMS и все сопутствующие готовые модули.

Нам часто задают вопрос: почему нельзя ту или иную коробку назвать фреймворком с несколькими готовыми модулями и применять подход разработки с нуля используя эту СMS.

Потому что CMS это не фреймворк, а именно модуль / плагин какого-то своего фреймворка со своей архитектурой. У коробок эта архитектура зажата и неповоротлива.

Подход№1: Когда говорят о написании проекта с «полного нуля» речь идет:

1. О создании сначала фреймворка. 
2. Потом о написании CMS плагина  под этот фреймворк. 
3. Написании модулей для этого CMS плагина.

Это нелегкий путь для изобретателей «своих велосипедов». Подход неплох и часто применяется при задачах которые решаются и вторым подходхом. Используется чаще всего только в стартапах без дальнейшей реинтеграции -  чисто под проект. Более трудоемок и бюджетоемок по сравнению со вторым подходом именно в части создания фреймворка, но также ничем вас не ограничивает в плане архитектуры.

Подход№2: Когда говорят о написании проекта на общепризнанном фреймворке (тот же symfony или zend):

1. Создание сначала фреймворка. Вы пользуетесь уже готовым профессиональным фреймворком.
2. Использование готовых модулей для фреймворка в том числе и CMS плагина для фреймворка.
3. Написание новых модулей под кастомные задачи.

Выбирая какой-то общепризнанный фреймворк вы  стартуете каждый раз со стадии №2 при этом абсолютно безпроблемно кастомизируете все, что у вас наработано на стадиях №2 и пишете все что требуется на стадии №3.  Подход от первого отличается лишь тем, что вы не изобретаете велосипед и при этом все также не имеете никаких рамок.

Прелесть второго подхода  (использование symfony или например Zend Framework)заключается в том, что, чтобы вы не начали писать на стадии №3 ничего не нужно трогать в стадии №1 и №2 т.к. там нет рамок к дальнейшим действиям. Хороший фреймворк это СВОБОДНЫЙ КАРКАС. Поэтому единственное что вас будет отделять от успеха это квалификация разработчика, а не рамки коробчной системы и прочая архитектурная ерунда.

Подход№3: Когда говорят о создании проекта на коробочной CMS:

1. разработка фреймворка. Система уже построена на своём уникальном фреймворке, но он не универсален и не так функционален как symfony, zend и прочие фреймворковые монстры. Чаще всего, это самописные системы, коробочный CMS плагин которых, поставлен на конвейерный поток.
2. написание плагина CMS. Собственно вы и используете готовое коробочное решение
3. Использование стандартных готовых модулей CMS.
4. Написание новых нетиповых  модулей для CMS если возникают кастомные задачи не предусмотренные набором типовых модулей.

Таким образом, если мы берем типовой проект и любую популярную коробочную CMS (тот же Битрикс), то мы начинаем почти всегда со стадии №3 третьего подхода.  Выбираем готовые модули и натягиваем на них скины и практически не переходим на стадию №4 т.к. она очень дорогая из за сложности в реализации связанной с негибкостью того, что заложено на 1 и 2 стадии.

Как только нам что-то не подходит (задачи шире базового функционала), мы начинаем последовательно опускаться на стадию №2  и если механика проблемы не вписывается в архитектуру системы этой CMS, то и на стадию №1 попутно переделывая все ранее готовое в стадии №2 (собственно перелопачивается ядро этой CMS).  Т.е. из третьего подхода проект плавно перемещаемся в Подход№1, неся при этом  колоссальные бюджетные и временные  затраты, на этот нелегкий  "путь китайского коммуниста".

Это как в строительстве – попытка надстроить пентхаус у дома, через смену фундамента. 
 

nadeyev

Вернуться к списку постов