MyCMS / Попытки / Теория создания CMS / Введение
Введение
Хотел написать большую развернутую статью, но понял одно - времени на такие вещи у меня нет, впрочем, как и на форумные обсуждения, а порой не хватает и на тестирование новинок на рынке web-разработок, а потому я принял решение написать цикл маленьких заметок из моей практики по созданию систем управления сайтами.
К сожалению, я не встречал хороших статей по созданию CMS-ок или FrameWork-ов, но это естественно не значит, что таких статей нет во многом наверняка мое незнание о них обуславливается все той же не хваткой времени. Но при этом, я не намерен утверждать, что данный труд является исчерпывающим пособием по теории создания систем управления сайтами или создания FrameWork-ов, но я попробую изложить свои мысли, а быть может кто-то из Вас найдет здесь некоторые интересные мысли которые в дальнейшем оформит в «красивой» форме.
Итак, как Вы наверное уже поняли, данная заметка полностью посвящена "воде", то есть я попробую изложить некоторые соображения общего характера, а в последующих статьях постараюсь приводить больше конкретики и меньше лирики.
Прописные истины о CMS, Framework и построении сайтов в целом.
Прежде чем начать проектировать CMS, давайте поймем, что мы хотим от нашей CMS и в чем же наиболее ярко выражаются отличия CMS и Framework.
Для простоты начну размышления с элементарного примера: Предположим у Вас имеется автомобиль, пусть это будет хороший автомобиль, напичканный различной электроникой комфортный, эргономичный и т.п., в общем отвечающий Вашим требованиям. При выборе этого автомобиля Вы отлично понимали, что индивидуальная модель на заказ - это очень дорого и Вам будет просто не комфортно заплатить за такое авто в десятки раз больше, нежели за вполне приличную и подходящую Вам серийную модель.
И покупая данную машину, Вы не задумывались о том, что в ней напихано, где надо подкрутить и какие запчасти добавить, чтобы машина заработала, Вы сразу сели и поехали в своем новеньком авто. Если же вы не рядовой клиент, а лицо представляющее тюнинговую компанию, то вполне возможно, что Вам не понадобится полностью укомплектованный автомобиль, то есть если Вы четко знаете, что купив данную модель, Вы намерены в ней поменять коробку передач и двигатель, Вам совсем необязательно покупать машину в наличии с этими частями. Данный пример хорошо иллюстрирует клиента и разработчика, а спроецировав данный пример на просторы web-а, мы легко заметим, что в большинстве своем все обстоит совсем не так как в машиностроении. И клиент и разработчик, в большинстве своем, полагают что выполняют индивидуальный заказ, при этом клиент пытается вымучить из себя тезисы для технического задания, а разработчик добросовестно выполнить их в соответствии с техническим заданием. Но для чего писать с нуля или делать _почти полную_ копию однажды написанной гостевой книги – для каждого клиента? И почему если сайты у всех клиентов столь индивидуальны, то по функционалу в сети они просто братья близнецы с еще тысячами сайтов? Да, я соглашусь, что обложка у этих ресурсов может быть разной, но это не значит, что мы должны переписывать функциональные блоки, ради обложки. Вернувшись в то же машиностроение, мы вновь проведем элементарную параллель – машины по своему оформлению, не смотря на свою одинаковую модель и комплектацию, могут быть оформлены совершенно по разному, но для этого совсем не обязательно переделывать кузов, двигатель и прочие части машины, достаточно ее просто перекрасить или сделать некие "надстройки". На мой взгляд в «сайтостроении» ситуация не должна координально отличаться, если мы создали много функциональный ресурс, то при создании схожего, мы должны всего лишь обновить его оформление, совершенно не затрагивая функциональной части. Ну а если автомобиль меняет комплектацию, то мы в своем деле просто делаем надстройки или заменяем некие функциональные блоки.
А теперь о ярких отличиях CMS и Framework. Готовый автомобиль - это CMS, автомобиль для тюнинга (например, без коробки передач и двигателя) - это FrameWork, то есть если вы заинтересованы в абсолютно готовом продукте вам нужна CMS, если же вы заинтересованы в частях из которых вы сконструируете индивидуальный абсолютно готовый продукт, то FrameWork. При этом отметим, что прежде чем CMS становится CMS она проходит стадию Framework, иначе просто «никак», то есть, сделав откат на несколько шагов в CMS мы получим свой FrameWork. Например, отключив все сценарии взаимодействия функциональных блоков и оставив только их вкупе с их методами, мы получаем обычный FrameWork. Теперь, у тех кто сомневался - что лучше делать CMS или FrameWork думаю не осталось вопросов по поводу того, что без FrameWork-а CMS у нас не получится.
Как я говорил, статья посвящена "воде", так что я продолжу :).
К моему счастью, незнаю как Вам, Cоветы окончили свое правление и в условиях нынешней экономики нашей страны и не только нашей, каждое предприятие ориентированно на получение прибыли. Нет, я не намерен объяснять Вам, что экономия времени разработки позволяет увеличить оборот и прибыль, я намерен порассуждать на тему того, для кого мы работаем. А работаем мы как мне кажется для клиентов, которые и обеспечивают нам прибыль. Следовательно, зададимся простым вопросом - что же хочет клиент, но ответ не так прост, проблема заключается в том что клиент пока, как правило, сам не знает чего хочет, да и не уверен хочет ли вообще. Извиняюсь за каламбур, но ситуация "на рынке сайтостроительства", как показывает моя практика, обстоит в большинстве случаев именно так. А потому, зарабатывают у нас менеджеры как и в любой другой отрасли, а люди творческие сидят на з/п, которая к тому же и не всегда блестит как хотелось бы :).
Но это я отклонился, вернемся к тому, чего хочет клиент, а не мы перво-наперво, клиент web-студии, если уж решил сделать сайт, он захотел на этом заработать, то есть, сделав некоторые вложения получить с них дивиденды.
Основную массу интернет-клиентов можно разделить на три категории - это те, кто хочет привлечь рекламой свою целевую аудиторию, те, кто хотят заработать на рекламе привлекая целевую аудиторию клиентов и те, кто реализует свою продукцию в интернете. Коротко - интернет-представительства, "независимые" порталы, и сфера услуг в интернете. Можно выделить еще и четвертую группу, чья доля на данный момент достаточно мала - это те кто использует интернет в качестве связующего звена информационных центров, но мы условимся, что мы не замечаем эту группу, потому как она всегда сама знает кого заметить и там несколько другие правила в отличие от большинства. А вот по первым трем категориям - не зависимо, к какой из них принадлежит наш клиент, он хочет, чтобы его ресурс посещался, чтобы он имел просто огромную популярность. Естественно обещать всем клиентам, что все их мечты сбудутся - абсолютное безрассудство. Но, тем не менее, разработчики ресурса, еще до того как над ним начали работу оптимизаторы, обеспечивают не менее 50% оптимизации сайта (для поисовых систем). А отсюда вытекает простая истина, если Вы намерены делать качественные сайты на базе своей системы, то вы просто обязаны знать основы SEO и по возможности прибегать к консультациям SEO-специалистов. Причем тут стоит отметить следующее, посещаемость важна для всех клиентов, львиная доля "притока" посетителей у всех новых и не только новых ресурсов - с поисковых систем, а поисковые системы в свою очередь имеют обыкновение менять правила «игры» по оптимизации ресурсов, не согласуя данные вопросы с владельцами сайтов или оптимизаторами. То есть, при очередной смене поисковиком алгоритмов определения релевантности страниц и введении новых правил индексации вы рискуете попасть в ситуацию, когда разом 30 клиентов придут к Вам с криками что "все падает", нужно срочно подстроиться под новые правила. И не имея единого механизма, на 30 сайтах Вы успешно будете каждый в отдельности подгонять под новые правила, за... например, 300$/сайт, в то время как, имея единую систему (хороший FrameWork или CMS), вы исправите алгоритм одного модуля (для поисковиков) и распакуете этот модуль на всех 30 сайтах за 1 день, сделав еще клиентам и скидку 50$, за то, что вы такие "быстрые", а они такие любимые :).
Что ж, подытожим в тезисной форме водную часть:
- Механизмы построения сайтов должны быть унифицированы.
- Решения типовых задач не должны дублировать друг друга.
- Каждый функциональный блок (по возможности) должен иметь возможность установки надстроек.
- Функционал сайта не должен зависеть от его дизайна (четкое разделение дизайна и кода)
- Без FrameWork-a практически не возможно создать хорошей CMS.
- При создании системы управления сайтом следует не забывать о интересах клиента.
На этом я закончу вводную часть добавив на засыпку три базовых тезиса
- Гибкость
- Скорость
- Надежность
Я постараюсь раскрыть все эти понятия в отношении CMS в своем цикле статей и я буду очень признателен, если Вы, уважаемый читатель спросите то, что Вы посчитали нераскрытым. Или думаете, что об этом стоит сказать, потому это и цикл статей, что его план всегда можно подкорректировать, правда плана нет – некогда мне составлять планы по такому творчеству, все мои планы – это программный код алгоритмы и голова (XP :)).
Владимир Бредихин 2006/04/18 00:29