Как стать автором
Обновить

Коробочное преимущество

Время на прочтение5 мин
Количество просмотров3.4K
Откровенно говоря, этот пост — комментарий к опусу Дениса Болтикова «Преимущества коробочной CMS перед студийной». Как правило, подобные темы я обхожу стороной, так как холивар — не то мероприятие, на которое я готов тратить своё время. Однако перечисленные Денисом преимущества повергли меня в шоковое состояние и заставили думать, что ему просто очень нужно пролобировать «коробку» на своём новом месте работы.

Копипастю преимущества, которые перечислил Денис:
  • Лучшее качество кода коробочной CMS. Для фирмы-разработчика эта CMS является основным продуктом. На ее разработку, оптимизацию, тестирование потрачено значительно больше человеко-часов чем у любой студии.Работоспособность коробочной CMS доказано на сотнях и тысячах созданных сайтах.Легкая расширяемость сайта. Большинство необходимых модулей уже создано. Надо интернет-магазин — подключаем, настраиваем, работает. Надо форум или раздел обратной связи — подключаем, настраиваем, работает.API для разработчиков. При его наличии грамотный программист легко нарастит нужную функциональность.Открытая документация. Есть документация пользователя, документация разработчика, документация по API для создания своих модулей. В большинстве студийных CMS этого нет или есть, но, как у топовых веб-студий за отдельную, довольно большую плату.Техническая поддержка, которая всегда готова помочь решить вашу проблему.Большое сообщество разработчиков. Найти специалиста, который доработает сайт на коробочной CMS значительно проще и быстрее, чем желающего копаться в чужом, и, как уже отмечалось, недокументированном движке. Написать с нуля и правда проще.Так сложилось, что как раз пару недель назад мы (kudzev, Warlock и я немного) закончили исследование двух CMS на предмет внедрения под конкретный проект с конкретными нуждами. Не буду объяснять почему, ибо долго, но в результате отсева, подопытными стали две самые шумные «коробки» — UMI и Битрикс.

    Краткий отчёт об исследовании в значительной мере контраргументирует доводы Дениса.

    Предмет исследования

    Для исследования выбраны две CMS – UMI.CMS и 1C-Bitrix. Исследования проводились в течении двух недель. В качестве источников информации выступали:
    • Исходные коды систем.Документации к системам.Форумы технической поддержки.Консультации сторонних разработчиков, имевших опыт работы с системами.Предметом исследований являлись:
      • Архитектура системы.Принцип работы с базой данных.Многосайтовость.Система прав.Качество написания кода.Время на разработку модуля «Модуль».Поддержка лучших практик.

        Результаты

        • CMS построена на современных технологиях PHP5, MySQL5, XSLT. Сама система является лёгкой как по объёму кода, так и по степени понимания.Архитектура системы построена по модульному принципу. Есть набор классов реализующих ядро и внешние модули. Ядро предоставляет довольно богатые инструменты для работы с файлами и базами данных. Модули могут использовать любую функциональность. Подключение модулей просто и доступно. Документация по ядру хорошая, по разработке модуля есть SDK.Работа с БД основана на использовании внутрисистемных объектов. Структура базы данных иерархическая в виде дерева. Прямой доступ к БД отсутствует. Структура таблиц в документации не описана. Данные сохраняются в таблицах в виде типов данных. Типы данных могут наследоваться и быть вложенными.Многосайтовость основана на парсинге URL. Многосайтовость реализована логически на основе одной точки входа с сохранением домена обращения.Система прав на уровне модулей. Реализация права на уровне операций не реализована. Но гипотетически реализовать возможно.Качество написания кода хорошее. Код написан прозрачно, централизовано. Комментарии присутствуют только в трудных для понимания местах.Время на разработку модуля «Модуль» — 2 дня. Модуль реализует задуманную функциональность примерно на 70%.Лучшие практики: полная поддержка ООП (насколько позволяет PHP5), централизованная обработка ошибок, шаблонизатор на основе XSLT, ORM на основе классов ядра, VO на основе типов данных, реализация FrontController с передачей управления модулям.
          • Известная система, имеющая богатую историю. Использует стандартные технологии PHP4, MySQL4. Система является очень избыточной и громоздкой, сложной для понимания.Архитектура системы построена по модульному принципу. Есть ядро и ряд подключаемых модулей. Подключение модуля является нетривиальной задачей и связана с большим количеством файлов для конфигурирования. Структура сайта физическая с созданием папок и файлов с дублированием в базе данных. Документация по ядру хорошая. Написать собственный модуль с нуля принципиально невозможно. Ядро предоставляет средства доступа к БД, но средства работы с файлами представлены в зачаточном уровне.Работа с БД может быть через системные интерфейсы, а также напрямую. Структура таблиц указана частично. Все данные в базе имеют метаинформацию, что влечёт за собой избыточность и перегрузку системы. Существует механизм сохранения данных как инфоблоки. Инфоблоки могут быть только в виде категории и элементов. И категории и элементы не могут быть вложенными или сложными типами.Многосайтовость реализуется на уровне веб-сервера и физического дублирования файлов.Система прав хорошая. Возможно организовать разграничение на уровне модулей и элементарных действий.Качество написание кода низкое. Основной причиной этого является явно плохая организация системы. Код разбросан по разным файлам и собрать целостную картину очень сложно.Время на разработку модуля «Модуль» 2 дня, модуль выполнен на 50% от задуманной функциональности. Корректировка администраторской зоны для своего модуля является самой сложной задачей в разработке модуля.Лучшие практики: частичная убогая поддержка ООП, обработка ошибок только на уровне 404, ошибки времени выполнения выводятся пользователю, шаблонизатор отсутствует (это просто ужасно), ORM отсутствует, псевдо VO через массивы, Front-ApplicationController отстутсвует – точек входа огромное множество (принцип первых сайтов на PHP через include).

            Заключание

            Ни та, ни другая CMS не подходит для реализации задуманной функциональности. Но если рассматривать с позиции того, что будет проще переделывать, то это UMI.CMS. Данная CMS более современная, она использует большую часть хороших практик и довольно легка в освоении и переделке. Bitrix, с точки зрения разработчика, – это устаревшая, громоздкая, избыточная система, которая до сих пор существует только за счёт хорошего маркетинга. Обе системы не были изначально, да и сейчас ориентированы на доработку, и их можно назвать закрытыми системами. Обе системы не реализуют один из основополагающих принципов построения web-приложений MVC (Model-Controller-View) – суть в разделении бизнес-логики, обработки событий и представления, а это влечёт за собой увеличение времени разработки и доработки в разы.Замечу, речь даже не о том, что студийная CMS лучше. Речь о том, что для того, чтобы делать выводы о преимуществах того или иного продукта, нужно оперировать конкретными примерами, а не собственными домыслами и коммерческой жилкой.

            Это было честное исследование. Выводы делать только вам.

            Update
            В комментах почему-то решили, что это пиар УМИ :( Но речь-то не о том. Речь о том, что есть проект и решение нужно искать под этот проект, а не проект подтягивать под возможности готовых решений.
Теги:
Хабы:
Всего голосов 68: ↑50 и ↓18+32
Комментарии141

Публикации