Поискать в Интернет
На сегодняшний день количество CMS (Content mangement system – Система управления содержимым) измеряется уже десятками. Как выбрать? И стоит ли вообще выбирать – может быть, как всегда, лучше всё сделать с нуля? В этой статье я постараюсь ответить на эти и другие вопросы обо всём, что касается CMS.
Зачем нужна CMS.
CMS, как следует из названия, нужна, чтобы управлять содержимым сайта и представлять его каким-то способом администратору сайта и конченому пользователю. А вот на вопрос «Как?» каждая CMS может дать свой ответ.
По способу генерации страниц различают следующие типы CMS:
1. Динамический тип. Такие CMS генерируют страницы по конкретному запросу пользователя (например /news.php?id=10). Информация для страницы выбирается из базы данных на основании переданных параметров. В базу информация заносится через модуль редактирования (часто называемый «Административный раздел»).
2. Статический тип. Такие CMS генерируют статические страницы на этапе редактирования. Фактически такие CMS можно назвать просто редакторами страниц.
3. Смешаный тип. Одним из вариантов такого типа CMS могут быть системы, выполняющие сборку конечной страницы по шаблону из статических блоков.
Понятно, что наибольшую гибкость и интерактивность может дать только первый тип, однако он же является наиболее требовательным с точки зрения ресурсов.
Для снижения нагрузки на сервер существуют системы кэширования как запросов к базе данных, так и собственно сгенерированных страниц с тем, чтобы потом просто возвратить сохранённые (закэшированные) данные и не загружать сервер лишний раз выполнением сложных вычислений. В некоторые CMS такие системы уже изначально встроены.
Некоторые CMS поддерживают возможность работы с разными типами баз данных, а так же умеют работать с юникодом и другими кодировками.
Преимущества CMS.
Основным преимуществом CMS является тот факт, что многое (если не всё) уже сделали за нас. Достаточно изменить несколько настроек, добавить необходимую информацию - и вуаля, новый сайт готов. Как это всё функционирует, нам знать не обязательно – нам предоставляют уже готовые интерфейсы (как программные так и графические) для использования уже реализованных в CMS достаточно сложных функций по обращению к базе данных, построению карты сайта, навигационной цепочки, выводу каталога продукции, разбитого постранично.
Нет ничего удивительного в том, что разработчики используют имеющиеся CMS, как платные, так и бесплатные, практически в любом проекте – ведь это здорово снижает время разработки, требования к квалификации как самого разработчика, так и заказчика (нужно просто договориться о том, какие модули использовать и «прикрутить» всё это к дизайну). А это, в свою очередь, обеспечивает большое число уже умеющих работать с каждой CMS людей.
Централизованная разработка (и доработка) CMS, единая документация и прочие прелести единого программного продукта – всё это не может не говорить в пользу использования таких систем.
Недостатки CMS.
Однако у каждой медали есть две стороны, и использование CMS имеет свои негативные стороны.
Как ни странно, но основным недостатком CMS является именно их универсальность – любое универсальное решение серьёзно теряет в гибкости, т.к. по сути своей не может учитывать специфику конкретной задачи. А в результате получается то, что мы можем наблюдать сегодня в рунете – все сайты становятся похожи друг на друга, как две капли воды и, казалось бы, очевидные, актуальные и удобные механизмы, просто необходимые сайту, на нём не реализуются – в CMS нет нужного модуля, а создать свой...
Тут мы переходим к следующему недостатку. Как уже было замечено, требования к квалификации разработчика, использующего при разработке CMS, заметно снижаются. Это, конечно же, не говорит о том, что все, кто использует CMS, не являются специалистами – но согласитесь, каков соблазн: не обладая серьёзной квалификацией заработать денег (или наоборот – сэкономить, сделав всё самостоятельно, не прибегая к помощи студий). И, к несчастью, этот соблазн оказывается для многих непреодолимым. А это никак не может положительно сказаться на качестве итогового продукта.
Когда же встаёт необходимость расширить имеющуюся функциональность сайта, то ситуаций может быть несколько:
1. В CMS есть необходимый модуль. Всё прекрасно. Но, к сожалению, так бывает далеко не всегда.
2. CMS имеет открытый исходный код. Это прекрасно, т.к. нужный модуль можно написать самому. Но здесь все преимущества от использования CMS сводятся на нет.
3. CMS имеет закрытый исходный код. Всё. Вариантов развития нет. Вам придётся ждать, когда в вашей CMS появится нужный модуль, либо менять CMS.
Ошибки CMS разработчик, конечно, устраняет, но лучше бы тем, кто использует CMS, никогда не видеть те баг-листы (отчёты о найденных ошибках), которые этот разработчик получает. И все эти ошибки будут вашими, если вы забыли скачать обновление, или оно доступно только за отдельную плату, а тратить на него деньги жалко. К ним прибавятся и ошибки, которые допустил тот, кто писал вам сайт с использованием этой CMS. (Это были вы сами? И это говорит о том, что ошибок нет?)
Вы вынуждены полагаться на разработчика CMS и верить, что он использует оптимальные решения, что не допускает ошибок, которые могут стать для вас критичными. (Из базы исчезли все заказы за последний месяц? Да всё нормально – это просто «глюканула» система очистки базы от устаревших данных, которые не используются более недели. Что вам важнее – место на сервере, или какие-то заказы? Ах, вы даже не знали, что такая система есть в CMS...)
Обычной практикой в разработке программных продуктов, к которым, без сомнения, относится и сайт, является использование, при необходимости, репозитария легко переносимых библиотек (модулей). По мере разработки продукта становится очевидным, какой функционал необходим. Если есть готовое решение для конкретной задачи, скажем, для работы с БД, то можно использовать его. Если нет – разрабатывается соответствующий модуль и заносится всё в тот же репозитарий, чтобы его можно было использовать в дальнейшем. Если вы решите заменить модуль на предоставляемый другим разработчиком, то у вас не возникнет с этим никаких проблем – просто измените реализацию некоторых своих функций, связанных с этой задачей (для БД основных функций, достаточных для работы, будет три: соединение, запрос и закрытие). А попробуйте встроить в одну CMS модуль от другой. При разработке сайта на CMS вы всегда должны иметь в виду, какими возможностями она обладает, т.к. дополнить эти возможности будет крайне сложно, тогда как цель (продукт) не должна подгоняться под имеющиеся средства (модули) – это средства должны выбираться в соответствии с поставленной целью. А иначе и правда получится, что при благой цели все имеющиеся средства хороши – других-то нет.
Аргументы специалистов.
CMS – это не панацея. Однако, про эти системы существует множество сказок, но, как все сказки, они справедливы только в некотором идеальном мире, где разработчики не допускают ошибок, где за работу в некоторой области берутся только специалисты в этой области, где разработчики CMS думают о каждом своём пользователе, а не о том, как заработать побольше денег, где однажды созданный сайт – на века, до того хорош.
Важным аргументом тех, кто призывает к использованию CMS, является то, что автор «самописного» кода может исчезнуть (увы, так, и правда, случается не редко), а разобраться в его коде будет потом ой как не просто – то ли дело, стандартная CMS!
Утверждающие это люди, видимо, просто не в курсе, что при приёме на работу на должность «программист» понимающие работодатели обычно пишут «умение разбираться в чужом коде». И делается это не только и не столько по причине, что действительно стоит такая задача – просто иначе получится, как в известном анекдоте: «чукча не читатель – чукча писатель». Специалисту всё равно, в чьём коде разбираться, а код Василия Пупкина и код CMS документированы зачастую одинаково, или, иначе говоря, - никак.
Не менее важным является и тот момент, что в коде разобрались не только будущие разработчики, но и будущие взломщики – я бы не назвал это мелочью, учитывая, что системы защиты большинства CMS далеки от идеала. Если же у CMS закрытый код, то плюс вообще теряется, а минус остаётся, т.к. для знания принципов функционирования системы не нужно детально знать её код, и такого «неполного» знания зачастую оказывается достаточно для злоумышленника.
Ещё один основной аргумент сторонников CMS – тот факт, что время разработки сайта на CMS сокращается в разы. Это так. Но при одном условии: разработчик является специалистом, хотя бы по работе с этой CMS. Но часто ли это так?
Не менее часто заявляется, что CMS проходит тестирование, а потому значительно более надёжна по сравнению с разработкой «с нуля». Но выходят всё новые и новые версии, в которых исправляются десятки ошибок – а сколько ещё осталось, не известно никому. Гордится своими баг-листами – это всё равно, что гордиться большим количеством пойманных преступников. Когда ловят мало, то это может быть и не от лени полицейских, а от того, что самих преступников мало, а если много ловят – то преступность точно высокая. От ошибок не застрахован никто, но в большой универсальной систем, коей является CMS, их допустить значительно проще.
Итоги.
В некоторых случаях проще бывает построить дом по шаблонному чертежу. Но и пристройку по собственному проекту к нему, так, чтобы она смотрелась хорошо, сделать уже не получится – то несущую стену нельзя трогать, то фундамент здесь слабый сделали для экономии материала – да мало ли непредвиденных обстоятельств бывает.
Получает ли заказчик то, что он хотел? Насколько создаваемые решения действительно являются оптимальными? Это никого не интересует. Ведь так просто научиться пользоваться какой-нибудь CMS и потом гордо всем говорить: «я – веб-разработчик!». Но это тема для отдельной, следующей, статьи «Искусство против ширпотреба».
А сейчас, подводя итог, могу лишь сказать, что я лично не вижу особого смысла выбирать CMS для сайта. Преимуществ у CMS и так не много, а они ещё и разбиваются о серьёзные проблемы со специалистами, т.к. разработчики CMS, в принципе, готовы сертифицировать любого – чем больше разработчиков сайтов на этой CMS, тем больше её популярность. А гибкость решений «с нуля», полный контроль разработчика и заказчика над ними, при прочих равных, остаются серьёзными преимуществами этого подхода. Но если уж выбирать, то CMS должна иметь открытый исходный код и иметь как можно более независимую модульную структуру.
Напоследок хочу вспомнить прошлое. В своё время популярностью пользовалось создание сайтов с использованием HTML-редакторов типа WYSIWYG – даже MS Word умел (да и умеет по сей день) создавать из свои документов HTML-страницы. Взгляните на сайты на narod.ru – и вы поймёте, о чём я говорю. Но сейчас люди, которые используют эти редакторы, даже сами стесняются назвать себя гордым именем «дизайнер». Я искренне надеюсь, что когда-нибудь и люди, использующие CMS, перестанут называть себя «программистами».
А. Кай
Разработчик web-студии "EVOUNIT"
(495) 765-51-43
evounit@evounit.ru
***
Создание web-сайтов, дизайн полиграфия