12 причин не использовать самописные CMS
08-01-2010 | Автор: Yaroslav.CH |
Рубрика: Система управления сайтом (CMS)
Метки: Заказчику
106
Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим CMS. И этим «заболеванием» страдают 99% разработчиков сайтов — в какой-то момент, в порыве инфантильного максимализма программист, многие десятки часов проведший «в обнимку» с кодом какой-либо системы, восклицает — «Доколе! Сколько можно возиться с этим убожеством?! Я же знаю как сделать лучше!» и мало-помалу «я знаю!» превращается в твердую уверенность «я могу!» и вот уже, глядишь, строчка за строчкой начинает вырисовываться костяк нового детища.
Однако всем хорошо известно чем и куда вымощена соответствующая дорога и потому любая, даже самая прекрасная идея, при неправильном подходе к ее реализации может обернуться проблемами для всех ее пользователей.
Ниже мы рассмотрим те минусы, которыми обременена практически каждая самописная система и причины по которым стоит воздержаться от ее использования.
Кроме того, на рынке присутствуют и бесплатные самописные системы, разрабатываемые одиночками-энтузиастами.
Под понятием «самописная CMS» подразумевается массовый продукт. Уникальные разработки, предназначенные для решения «одноразовых» нестандартных задач — в этой статье не рассматриваются.1. Жесткая привязка к одному разработчику
Представьте себе машину, которая разработана таким образом, что может быть заправлена исключительно одним видом топлива, который продает одна-единственная заправка в городе. При этом само-собой разумеется, что эта заправка является стопроцентным монополистом.
Ситуация с самописными CMS выглядит абсолютно так же — приобретая или устанавливая самописную систему, клиент попадает в полную зависимости от ее разработчика, которая выражается в следующем:
- все разработки, доработки и изменения CMS производятся только с помощью автора системы;
- изменение ценовой политики или лицензии на использование CMS находится исключительно в сфере ответственности автора;
- дальнейшее развитие системы или отказ от последующей разработки зависит исключительно от ее автора.
Говоря откровенно, автор системы может делать все, что ему заблагорассудится — закрывать разработку, продавать ее кому угодно, да хоть по примеру Одноклассников — ввести платные смс за регистрацию/скачивание дистрибутива/обновлений или встроить в последнее бесплатное обновление системы скрытый скрипт, скачивающий базу данных клиентов тех сайтов, чьи владельцы отказались платить за использование системы. Примеры, конечно, максималистские, но по факту автора практически ничто не ограничивает.
Пользователь же, наоборот — ограничен практически во всем и не может никоим образом влиять на политики лицензирования или же ценообразования. Даже в случае заключения договора на использование платной самописной CMS, учесть все пункты с одной стороны попросту невозможно, а с другой — сам автор не согласится на жестко регулирующие его деятельность пункты. В ситуации же с бесплатными CMS — система вообще поставляется под девизом «as is» — используете на свой страх и риск и за какие-либо возникшие в процессе эксплуатации ошибки или финансовые потери автор ответственности не несет.
2. Аудит безопасности
Основой любой системы является не красивый дизайн или удобный функционал, а безопасность. Согласитесь, никому не нужна CMS, пусть даже обвешанная всевозможными «рюшиками», но которую может взломать студент первого курса КПИ.
Но только вот вундеркиндов, способных совмещать в себе отличного разработчика, гениального системного архитектора и блестящего специалиста по безопасности — можно пересчитать по пальцам одной руки, а следовательно, вопрос защищенности системы чаще всего остается лишь на уровне знаний программиста-автора, а этого, согласитесь, никоим образом не может быть достаточно.
Да, конечно можно обратиться к компаниям, которые за определенную сумму проведут аудит системы, но а) это стоит хороших денег и б) аудит покажет «дыру», но не научит ее исправлять, а случаи «поднял зонтик — упала шляпа» известны повсеместно — где гарантия, что исправление одного эксплоита не приведет к появлению другого? И так может длиться до бесконечности. Именно поэтому аудит нужно проводить на регулярной основе, но авторы бесплатных самописных CMS чаще всего отвечают фразой: «а кто заплатит за аудит?», а платных — либо проводят его исключительно формально, что называется, «у Ашота» или же вообще обходят этот вопрос стороной, предпочитая потерять не в меру любопытного клиента.
3. Малая распространенность системы
Практически все, даже самые ярые противники Open Source признают, что пользовательский аудит может в определенной степени заменить профессиональный аудит безопасности — тысячи программистов и разработчиков, ежедневно модифицирующих систему под нужды клиентов, рано или поздно найдут ту потенциальную угрозу, которая может существовать в системе и добавят ее в багтрекер для последующего исправления официальной командой разработчиков или даже больше — просто сами пришлют готовое решение.
В случае же платной самописной CMS, количество таких пользователей сводится к самому автору системы, а бесплатной — к автору и небольшой группе «сочувствующих», использующих систему для своих нужд (чаще всего на малозначимых проектах и не слишком активно).
4. Проработка системной архитектуры
Учитывая тот факт, что проработка системной архитектуры имеет непосредственное и принципиальное значение для функционирования системы в целом, этот вопрос является одним из наиболее важных при старте разработки. И от того, насколько качественно была выполнена проработка, зависит вся дальнейшая судьба развития системы.
Учитывая, что заказчик обычно не способен оценить корректность архитектуры системы по причине закономерной недостаточности знаний в этой области, естественно этот вопрос остается на совести разработчика. Но как и в случае с безопасностью — вундеркинды встречаются крайне редко, а потому вопрос построения архитектуры самописной системы чаще всего раскрывается по методике — «не нужно изобретать велосипед». Разработчик берет за основу архитектуру одной из уже существующих популярных систем, вносит пару-тройку правок (но абсолютно не факт, что нужных и полезных) и говорит: «смотрите, моя новая архитектура революционна!».
4. Качество кода
Уровень кода самописных систем изначально равен уровню их разработчика, но поскольку это «спектакль одного актера», оценить этот уровень по-сути может только сам разработчик. Для пользователей это может быть чревато тем, что если на начальной стадии разработки — при минимуме функций — система будет казаться быстрее существующего аналога, то в дальнейшем это может обернуться теми же проблемами — перегруженностью, ошибками, несоответствием стандартным требованиям хостингов и т.д. В итоге получится, что пользователь поменял хорошо если только шило на мыло.
5. Программистам для программистов
Давайте вспомним, почему Windows, при всей своей проблемности и ошибочности, до сих пор занимает лидирующее место среди операционных систем, используемых пользователями? По простой, в сущности, причине — она проста для освоения и не требует специфических знаний.
От многих пользователей я часто слышу — «административная часть Joomla для меня сложна, а я не хочу разбираться». А, в сущности, в ней нет ничего экстраординарного — ее интерфейс лишь немного отличается от привычных «деревоподобных» интерфейсов. Но для многих уже и это становится проблемой.
Итак, помимо того, что наш автор должен быть разработчиком, специалистом по безопасности и системным архитектором — кроме этого, он должен быть еще и специалистом по юзабилити.
6. Отсутствие полноценной пользовательской документации
Документация — ахиллесова пята любого программного обеспечения. Из всех CMS, с которыми я за свою практику имел дело, адекватные руководства пользователя были только лишь максимум у пяти процентов систем.
Остальные же 95%, в лучшем случае описывались разрозненными статьями на тему «Как сделать...» или же инструкциями уровня «нажмите левую кнопку мыши», а в худшем — просто ничем, предоставляя пользователю самостоятельно догадываться о назначении того или иного элемента «методом научного клика».
7. Отсутствие API
Почему Twitter в одночасье стал настолько популярен? Почему Yandex.Карты с некоторых пор можно встретить практически повсеместно? Ответ прост — полноценный API, который позволяет программистам разрабатывать на его основе сторонние приложения.
И хотя API не является обязательным атрибутом CMS, его наличие ощутимо упрощает разработку сторонних приложений для сайта, таких как, например — связь с внутренними системами компании (SAP, SRM, модули электронной торговли и документооборота).
8. Проблема наличия лазеек
Разработчикам популярных Open Source или же проприетарных систем невыгодно оставлять какие-либо «черные ходы» по той простой причине, что в Open Souce системе они будут быстро найдены пользовательским сообществом, а в платных CMS с закрытым кодом — аудитом. Кроме того, если в отношении системы любого типа лицензирования хотя бы несколько раз будет поднят вопрос лазеек и будут приведены доказательства их наличия, то с популярностью и прибылью можно будет попрощаться раз и навсегда.
В случае же самописной CMS — таких гарантий нет, поскольку нет ни пользовательского аудита, ни специализированного. А малая распространенность системы позволит довольно легко скрыть наличие лазейки, если ее разработчик будет разумен и осторожен. Но только вот для пользователя такой системы это не сулит ничего хорошего.
9. Отсутствие профессионального сообщества и службы поддержки
Популярные Open Source CMS хороши своими открытыми сообществами, в которых можно быстро найти ответ на большинство типовых задач. Поддержка проприетарных систем управления всегда обеспечивается службой поддержки и help desk. А к кому обращаться в случае использования самописной системы?
10. Отсутствие поддержки сторонних специалистов (бес- и платных)
Ок, давайте даже попробуем оставить в стороне глобальное понятие сообщества и определить — кто же может выступать в качестве хотя бы уж советчика в вопросах использования самописной системы? И снова — только сам ее автор. Банально — кому задать вопрос, если что-то не получается? Однако учитывая то — сколько уже профессий должен совмещать в себе этот человек, трудно себе представить наличие у него еще и способности заниматься одновременно разработкой и поддержкой большого количества пользователей.
11. Отсутствие профессиональных тестировщиков
Многие считают, что тестирование — довольно простое дело. Казалось бы, ну чего там — сел, прошелся по функциям системы, выписал ошибки и отдал программисту на исправление. Однако на практике все далеко не так просто. Я не буду детально останавливаться на методиках тестирования, интересующиеся могут почитать отдельную статью в Википедии, достаточно полно раскрывающую общие понятия и профессионального тестирования программного обеспечения.
12. Отсутствие четкого вектора монетизации или скрытый вектор (для бесплатных CMS)
Все мы прекрасно понимаем, что разработка CMS — дело сложное и отнимающее много времени, которое может быть потрачено на разработку оплачиваемых проектов. Соответственно, автор системы должен каким-то образом покрывать недополученную прибыль. Например, одним из таких способов является перевод системы на коммерческие рельсы.
Процесс выглядит так — начала пользователям предлагается система в качестве бесплатного ПО, но с определенной версии (чаще всего той, с которой система приобретает более-менее завершенный и полнофункциональный вид), автор заявляет, что отныне все обновления будут платными. То есть все те, кто уже успел поставить, настроить и подогнать под свои нужды систему могут или оставаться на старой версии, либо же платной получать обновления.
Согласитесь, с одной стороны автора как бы можно и понять — мол, ну не может же человек заниматься таким полезным делом абсолютно бесплатно, но с другой, вернемся к п.1. — пользователь системы абсолютно зависит от желаний разработчика и выбора не имеет.
Второй же вариант развития событий выглядит и вовсе удручающе — автору в какой-то момент попросту надоедает заниматься не приносящей прибылью деятельностью или в его жизни что-то меняется и ему требуются дополнительные финансы (женитьба, рождение ребенка, постройка дома — мало ли что), но внутренние убеждения не позволяют принуждать пользователей платить за использование системы, а времени на ее разработку остается все меньше и меньше. А на donation долго не проживешь — наши реалии отличаются от западных. Закономерным итогом станет полное прекращение поддержки и в лучшем случае найдется тот, кто перехватит падающий «флаг» и продолжит разработку, а в худшем — система благополучно канет в лету.
Выводы
Исходя из всех вышеописанных причин, я всегда рекомендую заказчикам воздерживаться от приобретения или использования самописных CMS, поскольку ни единого действительно положительного момента в их применении нет, а головной боли они могут доставить крайне много.
Из своей личной практики скажу, что уже несколько раз я сталкивался с самописными CMS с такой архитектурой, что перенос сайта на новую систему в одном случае стоил заказчику на 20% больше, чем стоимость предыдущей разработки (не учитывая стоимость нового сайта), а в других — перенос приходилось осуществлять практически вручную, поскольку создавать систему импорта было просто нецелесообразно.
Подумайте, стоит ли оно того?
3 
170 
13
@© Yaroslav.Ch: вот это — считаю почти истиной.
«Основная проблема в том, что львиная доля эти гомункулусов сразу выбрасывается в свет и, более того, начинает предлагаться пользователям (как платно, так и бесплатно).»
Потешить ЧСВ — без этого многие начинающие программеры не могут. :-)
Спасибо! Вы ответили на многие мои вопросы.Я не использую самописные CMS. Для успешной продажи продукта нужен хороший продукт, хорошая цена и хорошая реклама, она не зависит своя система или чужая, но безопасность нужна той и другой.
@vovas: ну тешить Чувство Собственной Важности можно и каким-то другими путями, и кроме того, в большинстве случаев находится кто-то слегка по-профессиональнее, который радостно макает новоиспеченного «убийцу чего-то там» носом в его же продукт жизнедеятельности.
Проблема только в том, что чаще всего это происходит далеко не сразу.
@Иван: всегда пожалуйста и рад, что материал Вам пригодился :)
Замечательный блог, интересные материалы, буду заглядывать.
Вроде как все разложено по полочкам, но если брать конкретные примеры «самописных» КМС, из хотя-бы ру-говорящего нета, то нифига не понятно.
Итак, №1: MaxSite CMS — вроде самопис, но ведь заслуживает уважения / lдоверия? Хотя отпадает, поскольку там уже небольшое коммунити есть.
№2: семейство «танцующих» КМС, они же Румба (Румба ХМЛ, Румба Бланк, Румба Ньюс и тп). Да, разработчик один, но и сами КМС уже достаточно продвинутые на данный момент, и судя по отзывам сведущих в программировании людей, код у последних версий неплох, АПИ достаточно простое, шаблонизатор тоже не самый сложный, надежность — вроде не слышно, чтобы Румбу взломали...
№3: Блоголет — отличный проект, тоже самописный. И что? Имеющий прямые руки и светлый мосх программер не сможет использовать уже наработанное, и доделать при необходимости?
#4: NGCMS — тоже на сегодняшний день разработчиков не куча. Но проект уже в нынешнем состоянии догонит ДЛЕ, АПИ как-бы тоже не сложен (ну пишут же люди плагины, значит, не закрытый АПИ).
№5: Open Blog — разработка словенского программера(офсайт open-blog.info). По качеству интерфейса для конченого пользователя этот проект «сделает» все вышеназванные. Жаль, что он реально самотужный, и коммьюнити там пока увы, нет, а глюков хватает.
Что скажет уважаемый автор поста про вышеуказанные проекты?
И что он скажет про качество кода также «самописной» КМС xzengine (к сожалению, проект полумертв, или скорее мертв, так что вопрос чисто риторический)? Спасибо.
@Ацкий сисОдмин: спасибо за оценку и комментарий.
Я могу продолжить Ваш список еще пятью-десятью системами того же уровня, каждая из которых будет включать в себя пару-тройку пунктов из списка, приведенного выше. А еще могу прибавить столько же закрытых систем, разработанных студиями. Но только вот что это изменит?
Суть качественной системы в соответствии всем вышеизложенным пунктам, но не каким-то определенным на выбор. Да, я могу согласиться, что 90% соответствие можно приравнять к полному, но если из 12 пунктов соответствие можно найти только по 2-3, то это не будет верно.
MaxSite CMS: уважения — заслуживает, но доверия — объективным причинам пока нет. И тут дело не в Максе, которого я глубоко уважаю, а именно в самой системе. И никуда не отпадает по причине того, что единственный пункт, который можно исключить: наличие комьюнити, да и то не слишком активного.
Мы обсуждали с Максом его систему — например, тот же аудит безопасности пока что проводить не планируется, поскольку у него нет на это ни времени ни средств. Распространенность системы — покажите мне хотя бы один серьезный проект, который работает на MS CMS? Разработчик — только сам Макс. Зависимость — только от него. И т.д. Именно поэтому пока что я бы не рекомендовал ее использовать для своих проектов.
Кроме того, получить от Макса ответ на вопросы: «как долго будет продолжаться разработка системы» и «каким образом планируется ее монетизация» — мне не удалось, этот комментарий по каким-то причинам уже не был утвержден :)
Румба: насколько я помню, разрабатывается не одним разработчиком и это действительно семейство. За исключением некоторых моментов, ее можно отнести к состоявшимся системам.
Блоголет: лично мне в нем не нравится как минимум один серьезный момент — он изначально построен не на БД. Доработка — это вообще очень сложный вопрос, поскольку никто не знает какой уровень этой самой доработки потребуется. Если мы возьмем какой-то движок и перепишем в нем 90% кода — это будет вообще считаться уникальным проектом, не имеющим отношение к CMS.
NGCMS: как и румба — более-менее устоявшаяся система. Разработчиков несколько, что уже позволит избежать жесткой привязки. Хотя скорость ее разработки тоже не слишком велика, но вроде бы двигается. Но при этом форум — слабый, что явно показывает не слишком высокую распространенность и заинтересованность.
Open Blog: не видел, оценить не могу.
xzengine: могу сказать только то, что она мертва. Последнее обновление, если не ошибаюсь, было в 2008 году. Я ее увидел уже позже и потому даже не пытался оценивать.
А теперь у меня вопрос к Вам — представим, что я сделал клиенту сайт на Блоголете, но потом мои пути с заказчиком разошлись и он ищет нового. Какой процент разработчиков знаком с Блоголетом и будет готов взяться за дальнейшее развитие этого сайта?
Или Макс завтра бросит разработку MS CMS и куда вынуждены будут деваться те, кто организовал полноценный блог на его системе?
Да, можно сказать — Имеющий прямые руки и светлый мосх программер не сможет использовать уже наработанное, и доделать при необходимости? Да только вот в чем заковыка — зачем изначально брать движок, функционал которого потом придется допиливать силами отдельных программистов, которые должны будут предметно разбираться в системе? Слишком высоки издержки.
Взгляните на ситуацию с иной стороны — в статьях я в большей мере имею ввиду не личные, а коммерческие проекты. Это в личном блоге можно функцию дописать или нет — ничего не случиться, но в коммерческом так не может быть.
Поясню, почему я не приводил примеры определенных систем — любая из них (за исключением совсем мертвых) развивается и потому завтра может выйти из-под тени этого списка и перестать быть «самопиской», а превратиться в полноценную и серьезную систему.
А мониторить состояние каждой и редактировать постоянно пост — я просто замучаюсь :)
@© Yaroslav.Ch: позволю себе с Вами не согласиться, кроме описанных Вами минусов есть и свои большие плюс:
— абсолютная гибкость системы (все под один проект и все только под тебя, что хочешь — то и получаешь)
— скорость работы самописных кмс как правило гараздо выше (если учесть что ты не заказал самопись за 200 баксов под гиганский портал)
— Есть моменты которые возможно сделать только на самописи — возьмем к примеру интернет портал где идет работа менеджеров с прямыми рекламодателями — дак вот менеджерам нужна своя админка где будут выводится их контакты основанные на регистрации пользователей с поправками менеджера, плюс будет выводится время до снятие баннера, время когда он был снят и многое другое...
Ну ИМХО этих трех причин достаточно чтобы связываться с самописью ;-)
P.S. также хотел сказать на счет поддержки и привязки к одному программисту, в принципе почти вся компетентная поддержка платная — консультации на нубские вопросы на форумах не в счет, так что Вы можете спокойно обратиться к другому программисту и он в принципе сможет разгрести тот код и поправить его — PHP оно везде ПХП))))
@Deimos: то, что описываете Вы — это уже совсем другая сторона вопроса. Это не «самописная CMS», а уникальное программирование — разработка, которая создается под одного-единственного заказчика.
А я в статье никоим образом не постулировал, что для любых целей необходимо использовать только массовые разработки и более того, даже не касался вопроса подбора решений для проектов — это тематика одной из будущих статей :)
а) не всегда и б) можно, конечно, сделать бесплатную систему, но советы по ее имплементации — платными, но не думаю, что такой вариант пройдет. Альтернативой является — бесплатная система + платная имплементация + «как бы» платные советы в рамках заказанного внедрения. По такой формуле работает, например, большинство специалистов, оказывающих услуги по установке блогов на WordPress.
С чисто экономической точки зрения такой подход не имеет ни малейшего смысла. Поясню почему — представьте себе хотя бы тот же WordPress (не самая сложная система), но без строчки документации и с одним-единственным специалистом, написавшим-разбирающимся в системе. При этом рядом будет система Х, для которой есть и документация и пул специалистов.
Внимание — вопрос: на какой из систем есть смысл строить проект? :)
Спасибо за ответ. Действительно, не учел одного момента — вы пишете касательно коммерческих проектов. Тут вообще подошел-бы еще жеще — отбросил-бы даже движки под GPL, за небольшим исключением. Поскольку платит заказчик, то и делать ему, имхо, надо на коммерческих продуктах, ИМХО конечно.
Хотя, не исключаю возможных преимуществ GPL-проектов перед коммерческими.
Один серьезный проект на Максайт-таки назову: rybalka.tv. Хотя с вами полностью согласен — походу автор того проекта очень много чего доделал / переделал.
С другой стороны — достаточно старый проект Nucleus CMS, явно не попадающий под ваш расклад. Только вот уступает он нынешним «молодым» самописам. И тоже не возьмусь на нем поднимать даже собственный блог, хотя сама КМС мне очень нравится — админка там поудобнее многих, и другие многие вещи. Но будучи старым, он так и остался, походу, полуфабрикатом...
Кстати, возникает вопрос: а может, типа готовые КМС — это уже вчера. Может, будущее, или даже сегодня — за CMF (фреймворками или конструкторами)?
@Ацкий сисОдмин:
Спасибо Вам за интересные комментарии :)
Не соглашусь — все зависит не от типа лицензии или платности/бесплатности платформы, сколько от ее соответствия поставленным задачам.
В качестве примера можем сравнить объем усилий и затрат для создания сайта из десятка станиц на Битрикс (Неткат, Юми) или на WordPress. При этом не требуется никакой особый функционал — разве что простенькая форма обратной связи. Есть смысл покупать проприетарную CMS?
Кроме того, платность CMS далеко не всегда означает ее безопасность, дружественность и удобность. Опять же — посмотрите на тот же Битрикс, который стоит в максимальной редакции как крыло от истребителя, но удобством не отличается в принципе.
Было бы интересно узнать у автора — по какой причине он выбрал в качестве основы именно MaxSite CMS.
Честно скажу, я думал включить 13-м пунктом возраст проекта, но отказался от этой идеи по причине того, что возраст никоим образом не означает качество. Многие «динозавры» до сих пор работают на старой архитектуре, которая очень сильно ограничивает их развитие — плюшек и свистелок разработано уже много за столько лет, а вот что касается нагрузки и удобства — проблема, поскольку менять архитектуру крайне тяжело.
Скажу так — на мой взгляд, тут не «вчера» и «сегодня». Все, как и в случае с выбором — проприетарная/OpenSource система, зависит по большей части от поставленной задачи. Опять же, долго и упорно собирать из конструктора то, что уже готово — изобретение велосипеда. Но вот там, где требуются какие-то оригинальные, нестандартные и «самописные» решения — хороший CMF незаменим, поскольку точно так же позволят не собирать все тот же велосипед, а воспользоваться готовыми «кирпичиками».
В сущности, CMF, с моей точки зрения — продолжение CMS, появившийся в ответ на пожелания пользователей/бизнеса и программистов. Для первых это возможность получать сайты, увешанные большим количеством свистелок и плюшек, а также необходимость в платформах для реализации серьезных онлайн-проектов, а для других — реализовывать эти самые сайты без титанических усилий написания всего каждый раз с нуля.