Опыт перехода веб-студии с OpenSource CMS на коробочную UMI.CMS
Холивар
Безусловно, каждый разработчик будет хвалить именно ту систему управления, тот язык программирования и ту операционную систему, к которой он привык. Я нисколько не претендую на то, чтобы мое мнение считалось единственным верным. У каждого есть своя точка зрения, но я хотел бы рассказать, почему в итоге я выбрал UMI.CMS в качестве основной системы для разработки сайтов.
Длительный путь
Я имею достаточно богатый опыт разработки бизнес-логики для всякого рода систем управления. Так уж получается, что в большинстве случаев веб-студии испытывают явный недостаток специалистов, которые могут разбираться в короткие сроки с тем, с чем они раньше не сталкивались. Всегда можно написать некоторый код напрямую в обход API и вообще архитектуры системы. Однако, лично я такой подход не приемлю, и, как показывает практика, время и трудоемкость, которые будут потрачены потом на обновление и доработку такого рода систем, возрастают в разы.
Отсюда мне пришлось поковыряться в совершенно разном коде разных CMS, начиная от OpenSource-решений, типа Joomla, Wordpress, и самописных движках. Безусловно, также в разработке мне пришлось столкнуться с UMI.CMS и 1С-Битрикс.
Проблемы
Отсутствие централизованного управления со стороны производителя. Проекты, не имеющие внутреннего стержня — сильной и волевой компании-разработчика — разрываются на части разными направлениями развития, разными стилями программирования и разными подходами к решению задач. По этой же причине технические проблемы и баги большинства полностью opensource-систем приходится устранять силами собственных разработчиков
И что бесплатно?!...
В самом начале своего пути в направлении создания сайтов и разработки функционала, я предлагал клиентам использовать бесплатные системы управления, причем я честно был уверен в том, что коробочные решения — это пустая трата денег клиента. И, естественно, доволен был и клиент, так как он реально экономил. Также важным аргументом был тот факт, что для Opensource-решений разрабатывается большое количество платных и бесплатных модулей, которые можно использовать в рамках своих проектов. Для меня лично и в дальнейшем для нашей компании это тоже было удобно, так как не нужно тратить время на разработку каких-то решений, практически уже все есть в сети.
Однако, спустя какое-то время начали возникать всяческого рода трудности (например, где-то посыпались эксепшены, которые ничем не ловятся, или стали наблюдаться явные проблемы производительности), о возникновении которых я даже не мог подозревать. В итоге силами разработчиков приходилось копаться в коде модулей и самой системы управления и устранять баги. Иногда проблемы решались обновлением, а иногда, наоборот, это приводило к возникновению новых багов.
Первое знакомство
И, возможно, так было бы и дальше, стали возникать мысли о написании своей системы управления, которая не будет многофункциональной, а будет направлена для решения конкретных задач. Но пришлось столкнуться с крупным проектом, для которого было разработано много уникального функционала, и работает он под управлением UMI.CMS. В рамках данного проекта требовалась разработка нового функционала и доработки по старому. Так я и познакомился с миром UMI.CMS.
Признаюсь честно, было потрачено достаточно времени, чтобы понять для себя, как писать код под UMI. Однако, я считаю, это время не было потрачено зря. Я остался доволен тем, как подошли к делу разработчики ЮМИ, и мне нравится то, что у них получилось.
Сейчас мы практически полностью отказались от использования OpenSource для разработки Интернет-проектов. И смещаем акцент с 1С-Битрикс в сторону UMI.
А теперь больше конкретики, почему именно UMI.CMS. Я хочу затронуть весь спектр преимуществ с точки зрения разработчика и с точки зрения заказчика.
Архитектура данных
При работе с API UMI.CMS мы абстрагируемся от понятия базы данных, ее структуры, нативных sql-запросов, хотя реально это все используется, но скрыто в глубинах API. Разработчик, в терминах UMI, работает с объектами. Вся модель построена на взаимодействии объектов. Для получения объектов из внешнего хранилища используется понятие фильтра-селектора, который строится добавлением вызовов методов фильтрации. Объекты могут быть связаны между собой иерархически.
Чтобы получить список красных машин, мы просто указываем селектору тип объектов — машины, а также его характеристику — красный цвет и все. Селектор внутри своей реализации в стороне от разработчика строит sql-запрос, исходя из своей модели, и не требует от него знаний в архитектуре хранения данных и обращения к ним.
Реальная сериализация всех UMI-объектов происходит в одних и тех же таблицах. Рефлексия, или отражение, атрибутов объектов и его типа происходит по служебным полям таблиц, соединяя все представление объекта по ключам строк таблиц.
Решение
Объектно-ориентированная архитектура базы данных позволяет решать задачи проще и быстрее и обеспечивает высокую преемственность проектов между разработчиками.
Достоинства модели объектов UMI.CMS
С одной стороны, такая физическая организация данных через единое разложение данных очень гибкая и удобная, так как позволяет динамически добавлять объекты без расширения физической структуры и добавления таблиц (не плодятся таблицы), все данные имеют единое представление, что позволяет применять и реализовывать одни и те же единые алгоритмы и процедуры обработки данных.
Большинство известных мне систем управления имеют упрощенную модель хранения данных, которая подразумевает отображение каждого типа объектов на свою таблицу в БД. Такое построение позволяет составлять более эффективные с точки зрения производительности и сложности нативные sql-запросы, но менее гибко и более трудоемко для разработчика для реализации, требуя от него знаний по созданию таблиц, их организации, оптимизации. Также для каждого объекта нужно писать свои алгоритмы и операции по сериализации и десериализации, что требует дополнительных усилий и времени для тестирования и отладки.
Возникает вопрос, почему же для меня не имеют значение эти столь серьезные недостатки в организации данных в хранилище. Отвечу так: для корпоративных сайтов, интернет-магазинов, информационных порталов и социальных сетей, угрозы производительности не будет. Большинство проектов имеют не гигантский масштаб по нагрузкам и объему данных, а поэтому вариант с UMI.CMS позволит решать при достаточном уровне производительности подобные задачи. А для разработки крупных систем под высокими нагрузками я вообще бы не стал использовать PHP и MySQL, в такой ситуации я бы выбрал связку Java + Oracle. Но зато для разработки сайтов это удобная модель, так как позволяет значительно упростить работу. Наверняка некоторым программистам такое представление данных покажется неудобным, однако сразу скажут, что это предельно просто и удобно. За счет этого даже пользователь имеет возможность создать любой объект прямо через админку. Для этого ему не придется лезть в БД и создавать там новую таблицу, и разбираться, как и что там делать.
В процессе разработки
Существует достаточно полная документация по API, на сегодняшний момент есть определенные недостатки примеров, но такая ситуация есть у всех. Могу в защиту сказать, что ребята из «Юмисофт» постоянно работают над улучшением документации, также развивают свои источники информации: блог, вики и вики-дев. Также наличие «Службы Заботы» позволяет разрешать затыки и сложности в процессе разработки.
Видно, что UMI заинтересованы в своих партнёрах и клиентах, всегда идут им на встречу и помогают всеми возможными путями. Могу сказать, что это здорово, так как, возвращаясь например к Joomla, спрашивать не с кого, необходимо самостоятельно разбираться с возникшими трудностями, а вся серьезная документация, в частности по API, на английском языке, причем она очень часто меняется, что крайне неудобно.
Решение
Поддержка и гарантии производителя: постоянное развитие источников информации, поддержка Службой Заботы, устранение багов.
Кодинг
Вряд ли разработчик сможет сходу уверенно писать код под UMI, если начнет с ней работать впервые. Но по себе скажу, что чем глубже погружаешься, тем больше начинает нравиться процесс разработки на основе их API. Отмечу, что UMI думает о разработчиках и всячески пытается упростить процесс разработки, например, в версии 2.8 появился класс Selector, который позволяет предельно просто генерить выборки различной сложности.
Интеграция дизайна
UMI.CMS, в отличие от например той же Joomla, позволяет максимально просто внедрять дизайн, а также использовать на выбор два шаблонизатора tpl и xslt. В случае xslt вообще можно избежать написания кастомных макросов для сайта за счет того, что любой объект системы можно представить в виде xml.
Главное
Наиболее важная часть для клиента — это удобство управления своим сайтом.
Глазами клиента
Если провести аналогию, например, с Joomla и 1С-Битрикс, можно с уверенностью сказать, что UMI.CMS фаворит в плане управления сайтом. Видно, что UMI думает о юзабилити, так как все интуитивно удобно. Cейчас у меня есть отзывы клиентов, которые ушли от Joomla и перешли на UMI и довольны удобством ее интерфейса. OpenSource-решения, на мой взгляд, разрабатываются скорей для самих разработчиков и веб-мастеров, чем для потенциальных пользователей.
Для клиента в большинстве совершенно все равно, на чем будет работать его сайт, главное, что он хочет иметь возможность максимально просто им управлять. Я считаю, что UMI справилась с этим успешно.
В итоге всего выше сказанного, лично я для себя сделал выбор. На основе применения UMI.CMS можно строить и развивать надежный бизнес с уверенностью в качестве и высокой скорости разработки. Я надеюсь, что Вы тоже сделаете для себя определенные выводы после прочтения этого материала
»Роман Синцов,
руководитель проектного отдела студии MainSource
