Какая cms лучше?

Запарился я отвечать на этот вопрос, поэтому решил написать об этом в блоге.

Так какая же cms все таки лучше?

В течение своей карьеры я работал со следующими общераспространенными cms:

• Mamba, Limb – о да начало 2000 - x
• Joomla
• WordPress
• Umi cms
• Битрикс
• Abo
• DLE
• Друпал

Все перечисленные системы, платные они или бесплатные как правило, реализуют один и те же возможности похожими способами. Все они имеют шаблонизторы, поддержку тем, и еще кучу различного функционала.

Платные системы имеют отличные отзывы на всех технических форумах (не ведитесь - это тысячи обезьянок, зарабатывают свои 50 центов в час на банан), имеют яркую рекламу, вежливый суппорт и почую замануху. Однако, как только Вы заплатите деньги, и спросите суппорт, «а как мне доработать то и то», если это концептуальное изменение, вас весело пошлют лесом, указав пункт в соглашении, которое вы не читали. Более того, после выхода новой версии, все модули которые вы писали сами к старой версии, перестанут работать. И суппорт опять-таки пошлет вас лесом, указав, что не отвечает за ваши собственные разработки. «Хотите что-то уникальное – привлекайте наших спецов, по цене 40$ долларов в час».

Я не заметил никакого качественного отличия платных систем от бесплатных в качестве кода, применяемых архитектурных решениях и прочего. В случае с платными вы можете задавать тупые вопросы техподдержке, в случае с бесплатными, сами найдете в гугле, так как еще тысячи человек, вероятно, столкнулись с той же проблемой и более продвинутые собратья им помогли.

Плюс платные системы болеют откровенной паранойей (было бы что воровать!). Большинство из них будет работать только на домене localhost и на том, который указан в лицензии. А если вам захочется поднять две локальных копии одного движка, что к слову хочется часто из соображений (эталон – мой вариант), вы получите жестокий облом. Некоторые участки кода у платных cms обфусцирвоаны или требуют установки Zend Optimizer, что затрудняет работу с ними. В остальном качественных отличий от бесплатных аналогов нет.

 

Так какая же лучше?

А давайте вернемся на шаг назад к такому интересному документу как ГОСТ 34.601-90.

Да, да, в те былинные времена, когда Прибалтика покидала дряхлеющий под руководством Горбачева Колосс, а пьяный Ельцин с шайкой соратников готовил Беловежскую пущу, группа депутатов СССР, еще исполняющих свои прямые обязанности описали стандартный и логичный порядок разработки Автоматизированных систем(АС), который актуален как тогда, так и сейчас, через сто лет он будет не менее актуален.

Полный текст ГОСТа тут: ГОСТ 34.601-90.

Ваш веб сайт, тоже является автоматизированной системой, поэтому стадии создания АС относятся к веб сайту в самую первую очередь. Давайте, их перечислим:

1. Формирование требований к АС – иными словами Вы описываете, что должна делать автоматизированная система, что Вы хотите получить и каким образом желаете автоматизировать Вашу работу.
2. Разработка концепции АС. – исходя из этих требований группа программистов думает как лучше переложить их на языки вычисления, чтобы выполнить в максимальном объеме, с максимальной эффективностью. Именно тут закладываются такие вещи как быстродействие системы, оптимальная архитектура, расчет на высокие нагрузки и прочее.
3. Техническое задание – далее описывается техническое здание на создание АС, выверяется не забли ли ничего учесть
4. Эскизный проект – в случае с веб сайтом, таким проектом является дизайн в формате psd
5. Технический проект – проводится комплекс работ, по созданию из дизайна готового веб сайта (верстка, насадка на движок, программирование всей бизнес логики, включая вашу уникальную)
6. Рабочая документация – составляется документация на созданную систему
7. Ввод в действие – непосредственно перенос сайта на Ваш хостинг, обучение сотрудников и т.п.
8. Сопровождение АС – это из области: «Анатолий, а у нас при сохранении новости вылезают какие-то страшные надписи». И Анатолий кидается искать причину и устранять неполадку.

 

Вот утвержденные проверенные временем столпы, четкое соблюдение которых позволяет гарантировать решение задачи любой сложности.

А каким образом используются готовые cms.

Все cms рассчитаны на такую схему работы с ними:

1. Вы скачиваете движок
2. Выбираете из большой коллекции шаблон,
3. Жмете пару кнопок шаблон автоматически насаживается и вуаля, Ваш сайт готов.

Просто, правда? Самое интересное, что это Вы можете сделать сами без программиста. Создатели так и полагают.

Вернемся к нашим ГОСТам
Выбор эскиза – здесь заменяет стадию 4, а запуск cms стадию 5. Рабочая документация скачивается с сайта разработчиков, ввод в действие и сопровождение проводятся как обычно.

Не правда ли чего-то не хватает? А чего же? Пунктов 1-3. Тех самых важных – формирования требований и разработки архитектуры.

Иными словами Вам сразу предлагается готовый, законченный продукт.

В то время как в жизни, мы сначала думаем, формулируем требования к результату, а потом что-то делаем.

Иначе поступают только психбольные – сначала делают, потом думают как это действие представить и подогнать под ситуацию. «Ой, не обращайте внимание я всегда так здороваюсь».

Итак, Вы скачали то, что не совсем Вас устраивает. Как решается эта проблема в «универсальных» cms? А вот это самое интересное. Сформировать и реализовать требования к АС, нам предлагают потом, по факту, на уже готовой АС. Делается это посредством плагинов, расширений, кучи настроек и тому подобного.

Если провести аналогию с домом. Сначала строится готовый дом. Потом Вы приходите и говорите: «Мне бы кухню расширить» «Гавно - вопрос», - отвечает строитель, подпирает ломами несущую стену и двигает ее на метр влево. Это программист устанавливает расширение. «А что это у нас потолок треснул и разошелся?»,- спрашиваете Вы. «Гавно - вопрос», отвечает строитель и устанавливает плагин «Натяжной потолок». Теперь не видно трещин? Но они-то не пропали. «А вот труба каминная перестала работать?», - «Гавно - вопрос», давайте мы дырку для дыма пробьем под камином, раз потолок уже для этого не годится, он же натяжной.

А надо Вам еще одну комнату? Мы вручную заложим половину комнаты кирпичами, а поскольку ни один честный человек, взглянув на такой дом, не захочет чтобы его имя было в списке строителей, пригласим поддатого Ваньку, заплатим ему в два раза дороже, и он обязательно проложит стенку. При это загадит цементом шелковые обои (дом-то уже был готов), в нескольких местах осыплется штукатурка, но Ванька-то должен был стенку покласть и он это сделал на все пять, стена получилась что надо, правда без штукатурки и другого цвета, зато ломом не прошибешь. Так что он уходит, довольно перечитывая деньги, а дом остается Вам. Приятного новоселья!

Это не метафоры, это не ужастики, а именно так выглядит рабочий процесс при работе с универсальными движками.

Это если Вы хотели сайт визитку.

А если Вы хотели что-то изначально необычное, например дом в готическом стиле, ажурными верандами и башенками? Представляете, сколько сил уйдет, чтобы сделать это из обычного типового домика? Снести одну из несущих стен - Веранда, каким-то чудом на хрупкую крышу водрузить тяжелые башни, скачанные с сайта СуперБашня.ком (главное чтобы они не рухнули ДО подписания Акта приемки), навесить лепнину на шелковые обои ( у нас не было бюджета на их обдирку и повторную наклейку).

Эта метафора полностью описывает получаемый результат. Не верите?

Если бы Вы знали сколько за свою карьеру я насмотрелся на плагины, делающие по 50, а то и 100(!) запросов к базе. На языковые расширения, которые ругулярками парсят весь буфер и поставляют слова из базы данных. Причем выборка слов из огромного словаря идет методом LIKE. И так на каждое слово. Список новостей, делающий 40 хитрых запросов с джоинами к календарю, которого тут быть не должно и разработчики его просто спрятали. Но плагин-то продолжает работать во всю силу.

На момент подписания акта – все работает, но когда данных становится много в таблицах, заказчик был искренне удивлен, а почему сайт грузится по 15-20 секунд? «А подскажите программиста, кто это починит?» «А подскажите строителя, который мне еще, что-нибудь налепит, типа подпорок под потолок на котором стоят башни, чтобы он сыпался при сильном ветре». Не удивительно что честные строители будут от вас шарахаться

Последний раз, оглядев все это на сайте одной всемирной организации, я выработал на нашей компании четкое правило: никогда не за какие деньги не браться за доработку универсальных систем после других разработчиков. И самом не работать с ними. Мне стыдно за то, что я в этом участвовал. Это было в последний раз.

 

Программный код самих cms далеко не фонтан. Домик, начальный далек от совершенства. Но что там делается после попыток реализовать причудливые фантазии заказчика. Это тихий ужас.

 

Какова же причина? Причина все та же: пропущенные пункты 1-3 при самом начале работы.

Запомните, ни одна универсальная cms не может эффективно реализовать ваши пожелания, так как вы не формулировали требования и концепцию к ней, при ее создании. Она расчитана не чтобы решать вашу задачу, а чтобы решать все задачи. Универсальное решение всегда хуже целевого. «Нелья объять необъятное», говорил Козьма Прутков еще в 18-м веке. Это всегда будут костыли, треснутые стены, башни на хрупком потолке, дым, идущий в комнату. Не будет чудес.

Что же делать?

Ответ прост. Если позволяют бюджеты, обратится к разработчикам ПО, которые предложат вам все 8 стадий разработки, описанных в ГОСТе.

Которые будут не готовую cms допиливать под Ваши нужны, а строить Ваш собственный дом, по Вашему собственному чертежу из кирпичей. В качестве кирпичей могут выступать Фреймворки, или прошлые наработки разработчиков. Вот это – именно кирпичи, они предназначены для самых универсальных и гибких композиций без потери качества. А cms – это уже готовые дома, которые очень тяжело дорабатывать, если изменения концептуальны.

Если же бюджеты маленькие, следует выбрать cms готовую, которая максимально близка к вашим требованиям. Там должно быть все что вы хотите на 100% и в том виде, в каком вы хотите. Если чего-то не хватает, следует не дергать несущие стены, а отказаться от хотелок. Только так Ваш готовый домик будет еще как-то стоять.

Так какая же cms лучше?

• Joomla – 1.5 – хороша для визитки
• WordPress – для простого блога
• Битрикс – для магазина
• Дле - для очередного портала аля Фишки.ру (который никогда не раскрутится)

И только в том случае, если стандартные реализации Вас полностью устраивают.

Безопасность

Отдельной тема является безопасность универсальных движков. Их код всегда одинаков, на десятках тысяч сайтах стоит одно и то же ядро. И это ядро можно без проблем скачать и просмотреть. Хакеры постоянно находят в коде все новые и новые уязвимости (это естественно, ведь написать миллионы строчек кода без логических ошибок практически не возможно). Имея уязвимости можно всегда написать универсальный скрипт, который используя их, позволит получить контроль над сайтом в считанные секунды, без каких либо глубоких технических навыков. Сначала продавать его, а потом по мере насыщения «черного рынка» и вовсе выложить в открытый доступ, на всякие файловые обменники, которые платят за число скачиваний. Это называется «эксплоит». Именно ими тупые малолетки «взламывают» повально сайты, чтобы самоутвердиться. Армия за признание Косово, Армия за независимый Курдистан и прочая лабуда.

Безусловно разработчики cms всегда обновляют свои версии и латают уязвимости. Таким образом, чтобы Вас не взломал 12-летний оболтус, Вам надо постоянно обновлять вашу cms. А теперь посмотрим в самое начало статьи. И в случае с платными и в случае с бесплатными, есть все шансы, что часть ваших стен и примочек, отличных от стандартной комплектации рухнут, погребя под собой все живое. В случае с платными они рухнут обязательно, потому что компаниям создателям надо еще как-то продавать услуги своих дорогих и ленивых программистов.

 

Выводы.

Если Вы планируете что-то необычное, уникальное, не имеющее аналогов, только мошенники могут предложить Вам пытаться сделать это на базе «универсальных» cms.

Как же так спросите Вы, ведь есть хорошие разработки на этих системах, которые держат большие нагрузки те же сайты представительств, откуда Вы их скачали и многие другие. Конечно, они есть. Но как они делаются? Если вернуться к нашей аналогии с домом, то делаются они так: Сначала дом сносится под корень. Потом формируются требования, архитектура, а далее из обломков дома как из б.у. кирпичей собирается что-то достаточно приличное и прочное. Только вот парадокс, цена такой разработки будет выше(!) чем цены на разработку с нуля на фреймворках. Потому как дом надо еще снести, и обработать каждый кирпич. Если говорить техническим языком – надо основательно переписать ядро (а для этого выучить наизусть как оно работает, а это тысячи строчек некомментированного кода), убрать все лишние настройки, плагины, создающие нагрузку, написать свои целевые решения, и внедрить их. Никто из предлагающих услуги по работе с готовыми cms за 500-800 баксов не имеет ввиду такой работы. И если Вы ее потребуете на Вас будут смотреть как на сумашедшего. «Это не возможно», будет самым частым ответом на все Ваши пожелания Тех же кто все-таки это делает Вы узнаете по ооочень серьезным ценам и солидным клиентам.

Вы еще уверены что хотите писать Ваш новостей портал на Жумле, новостной портал с огромным числом читателей на Вордперссе, а необычный и имиджевый магазин на Битриксе?