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
@Павел: добрый день и спасибо за комментарий и оценку.
В сущности, все зависит от того — какие требования к функционалу Вы предъявляете изначально.
Если в основе лежит стандартный функционал большинства CMS — например, новости, статьи, рассылка, галереи, доски и прочее (см. описание любой крупной CMS) — можно не морочить себе голову и реализовать сайт на основе готовой системы.
Если функционал, скажем так, «относительно нестандартный» — есть смысл взять готовую CMS и модифицировать ее до нужного Вам уровня. Например, Вам нужно сделать социальную сеть — Вы берете или Drupal или Joomla и дорабатываете готовые модули.
В этом случае уже необходимо выбирать ту систему, возможности которой наиболее близки к тому, что Вам необходимо — будет быстрее и дешевле.
В том случае, если функционал абсолютно нестандартный — можно взять за основу готовую CMS, использовав ее для управления самим сайтом, а функционал реализовать в качестве standalone приложения — например, как отдельный модуль этой CMS. Это позволит упростить и удешевить процесс разработки, за счет использования некоторых готовых решений (например, управление структурой, пользователями и т.д.) от готовой CMS, а основной функционал уже писать отдельно.
В этом случае Вы так же будете зависеть от разработчика — но это ситуация вынужденная и решить ее можно только с помощью очень детальной документации, которую в последствии, в случае возникновения проблем, можно будет передать другому разработчику.
Если же функционал является чем-то настолько уникальным, что вариантов нет вообще никаких — это означает, что CMS ему попросту не нужна. Ни готовая, ни самописная. Это будет отдельное standalone решение, которое разрабатывается уже по другой модели.
Точнее сказать трудно, поскольку, к сожалению, Вы не указали даже основу будущего сайта.
@© Yaroslav.CH:
Спасибо за Ваш ответ.
По своей сути наш сайт это электронный каталог электроизмерительной техники (фотографии, технические описания, цены). Сайт должен продавать (но это не интернет магазин, конечный договор делает менеджер по телефону). Коммерция через сайт не ведется. Сейчас на старом сайте около 9000 товаров.
До каждого отдельного товара каталога или подрубрики должна быть возможность прикрепить отдельных : ответственного менеджера, файлы, FAQ, опросы, глоссарий, две цены (грн руб), а также товаров на распродажу или на покупку, автоматический подбор уникальных тайтел, дескрипшин, кейвордс, возможность добавления к товару новостей, акций, статьи и другое. В общем, все утилиты для нормального предоставления клиенту информации про товар. Экспорт и импорт товаров всех и из отдельных рубрик.
Также на сайте есть стандартные опции типа Наши Услуги, Вакансии, О нас.
Сейчас функционал простой не чем не сложнее обычного интернет магазина. Каких-то сложных алгоритмов и нестандартных задач не прогнозируется. На будущее планируется дописывание отдельных не сложных модулей, но это развитие — так должно быть.
Основной упор ставиться на очень хорошее автоматизированное SEO о чем вы уже написали в своей статье «10 обязательных SEO-пунктов любого Технического Задания на разработку сайта» с чем я полностью согласен.
Основное сейчас для меня это подобрать наиболее подходящее CMS.
@Павел:
Тогда стоит смотреть в сторону модулей интернет-магазинов с функцией отключения корзины.
Этот пункт не совсем понятен. Требуется разделение прав доступа к разделам магазина? На мой взгляд, это не обязательно решать техническими средствами — достаточно и организационных.
Значит магазин должен поддерживать функцию электронных товаров.
FAQ и глоссарий оптимальнее делать общими, добавив функционал, позволяющий автоматически проставлять на соответствующее слово — внутреннюю ссылку на нужную страницу глоссария или ответ в FAQ.
Делать отдельный опрос под каждую рубрику можно, но для этого нужно быть четко уверенным, что при 9000 товаров у Вас банально хватит вопросов.
Магазин должен обладать функцией валютного конвертера или можно сделать просто два поля для вывода цены — зависит от Ваших пожеланий в отношении их публикации. Либо нужно отталкиваться от одной, конвертируя ее в другую, либо же вести просто две раздельные цены. Это уже момент политики ценообразования Вашей компании.
Распродажи — обычный функционал для толкового скрипта магазина, реализуются по принципу — скидки на товар, скидки на группу товаров и т.д.
Эти моменты входят в саму CMS, но сложного обычно нет ничего, поскольку для title берется название товара, а для description — его описание. Но в этом случае нужно очень серьезно работать с описаниями.
Зависит от того, как Вы себе видите эту реализацию — можно вручную, а можно — автоматически.
Нужна поддержка XML со стороны CMS или модуля каталога.
Скажем прямо — хорошего автоматизированного SEO не бывает. Если Вы хотите действительно качественное SEO, тут придется серьезно поработать руками над каждым товаром и категорией.
Не могу сказать, что все перечисленное является стандартом для обычного интернет-каталога, но и говорить о том, что требуется какой-то вариант standalone решения тоже смысла не имеет. Часть вещей нужно будет дописывать, но это не критично.
Реализовать все это можно и на бесплатных CMS и на проприетарных — но смотреть нужно в первую тройку. Drupal, TYPO3, Joomla/Virtuemart и Bitrix, UMI.CMS, Amiro.CMS.
На Open Source CMS собрать такой каталог полностью на бесплатных модулях не получится (как минимум, я не помню подобных) — нужно будет докупить некоторое количество платных, а на платных CMS — некоторый функционал нужно будет дописать.
Это обычный ход на тему — «как продать свою систему и подсадить заказчика на обновления у нас». Основываясь на том, что Вы написали, ничего особо выкручивать не надо — все это довольно стандартный функционал, просто часть из которого надо взаимосвязать друг с другом.
Скорее, Вам нужно подобрать себе толкового разработчика.
Например, на сайте Битрикса, Амиро или Юми есть возможность разослать заявку на разработку сайта, всем официально зарегистрированным разработчикам на этих CMS.
Для Битрикс можно прямо приложить ТЗ, для UMI — хуже, указывается только тип сайта и бюджет, а у Amiro — нужно заполнить бриф.
Для этих CMS воспользуйтесь этими сервисами, а для бесплатных — попробуйте биржи фрилансеров. Там, само собой, присутствуют не только студии, но и одиночки.
Думаю, Вам стоит просто собрать всевозможные варианты предложений и выбирать уже среди них ту студию или отдельного разработчика, работы которого Вам понравятся. В любом случае, какую бы CMS Вы не выбрали — но разработчика на ней искать придется отдельно. Поэтому, я и предлагаю пойти от обратного.
Но так или иначе, какой бы вариант не был финальным выбором, Вам обязательно нужно очень серьезно отнестись к вопросу полноценной документации — даже на готовых CMS часть будет дописываться и лучше знать — что и как делалось.
В сторону самописных CMS я бы не смотрел — использование готовой позволит хотя бы снизить риски при поиске разработчика. Даже если Вы в процессе поймете, что все «типичное не то», в конце-концов, можно заплатить только за сделанное и взять нового. А с самописной системой так не получится — придется оставаться уже с тем, с кем начали работать или полностью отказываться и начинать все с начала. Даже на готовых системах с дописанным функционалом — и то возникают подобные проблемы, а на самописных — на мой взгляд, этот риск просто неотъемлемая составляющая сотрудничества.
Ярослав помогите мне определится с CMS.
Я никоем образом не буду расценивать это как рекламу, а просто как результат вашего опита работы в данной сфере.
Брать самописную CMS я точно не буду.
Не могу выбрать между Bitrix, Drupal и Joomla. «Бесплатность» системы роли не играет основное здесь:
— большой, но понятный функционал, подходящий под мои потребности;
— возможность легкой доработки после сдачи мне сайта разработчиком;
@Павел: для того, чтобы однозначно сказать — «берите вот это, а вот это — не берите» нужно внимательно читать ТЗ, прикидывать функционал и подбирать систему.
Иначе — это не вариант и дело даже не в рекламе, а в том, что применить опыт при оценке «на пальцах» толком не получится. Поэтому, я могу только рекомендовать «в общих чертах».
Все три системы давно существуют на рынке и работают достаточно адекватно и стабильно. С точки зрения реализации, сделать то, что Вы вкратце описали выше — можно на всех трех. Повторюсь, Вам нужен нормальный разработчик, которого можно выбрать по методике, которую я изложил комментарием выше.
Вся проблема заключается в том, что Битрикс и Друпал — это не CMS в принципе, а практически CMF. Да, на обеих системах есть готовые модули для интернет-коммерции, но они изначально рассчитаны на то, что их их частей будут собирать то, что нужно.
Joomla\Vitruemart — готовое решение для среднего интернет-магазина, но под Ваши нужды нужно будет дописывать или докупать платные модули уже непосредственно под магазин.
То есть, в любом случае, Вам нужен нормальный и толковый разработчик, варианты поиска которого я изложил в предыдущем комментарии. На мой взгляд, Вы не совсем с той стороны подходите — Вы пытаетесь, не зная преимуществ и недостатков систем, выбрать CMS, а уже под нее брать разработчика. Оптимальнее, как я уже говорил — разослать свое предложение и ТЗ разработчикам на разных системах, а после выбрать, допустим, 3-х наиболее толковых, встретиться с ними и обговорить их предложения.
Кстати, именно поэтому я в самой статье и не приводил в пример ни одну CMS — в ней изложена лишь моя точка зрения на общий принцип выбора.
И есть еще один момент — исходя из логики CMF, порекомендовать ту или иную систему можно тоже с большой натяжкой. Все зависит от того, кто будет Вам на ней разрабатывать сайт. Например, на том же Bitrix есть масса хорошо работающих проектов, а масса — просто ковыляющих и еле-еле сделанных. С Drupal — ситуация аналогичная. С Joomla\Vitruemart — все несколько по-другому, поскольку магазин обычно все берут уже готовый и дописывают/докупают к нему определенные функциональные ячейки.
Но, опять же, 100% сказать — «Вам нужен готовый магазин» или «Вам нужен CMF» без детального ознакомления с ТЗ — не получится. Даже те моменты, которые Вы изложили в комментарии, при разработке могут пониматься двояко — может быть Вам достаточно просто «полуавтоматического» решения, а может быть — нужно строить отдельную автоматизированную систему. Все зависит от ТЗ и Ваших пожеланий.
Лично мой выбор Joomla ( но только потому что я очень люблю GNU и вообще свободно распространяемый софт) . P.S. а что такое ТЗ? чтото там Задачи?
@Kabban: ТЗ — сокращение от техническое задание.
Вся беда в том, что за последние несколько лет произошла грубая подмена понятий в отношении CMS, превратившая ее из системы управления контентом (вдумайтесь!) в иррациональную систему построения веб-сайтов!
Почему?
Да потому, что — удобно!
Удобно нажать несколько кнопок, что-то куда-то перетащить, натянуть на шаблон и сайт готов...
Н-у-у не д-о-о-лжен скрипт собирать главное меню простого сайта по несколько десятков-сотен раз в секунду, если это можно сделать единожды вручную! А сколько таких пустых задач в современной CMS, порой раскаляющих сервер докрасна?..
@Zares: спасибо за комментарий.
Честно говоря, вопрос сложный — с одной стороны, возможно, и правда, что ощутимая часть CMS превратилась в комбайн для практически разработки сайта, но с другой — любой блок, виджет или инфоблок можно тоже считать контентом и система должна предоставлять возможность им управлять. В противном случае все упрется, по-сути, только в WYSIWYG-редактор для текста страниц и на этом вопрос контента можно будет считать закрытым — а так не годится.
Кроме того, CMS зачастую позволяют очень сильно упростить процесс разработки для несложных сайтов — тех, которые не требуют серьезных решений.
Но те разработки, которые касаются standalone-решений всё также нужно писать с нуля, поскольку ни одна CMS их не покрывает. То есть, по-сути, CMS позволяет лишь упростить рутинные операции и снизить порог вхождения.
Вот тут, честно говоря, не совсем понял Вашу мысль — что имеется ввиду «вручную»? Вернуться к временам pure HTML и использовать только его для создания сайтов или применять логику генерации скриптами готовых страниц и отдавать уже именно их пользователю?
P.S. Понравились статьи (и, конечно, мысли в них) на Вашем блоге — подписался, буду читать.
если разработкая занимается профи который шарит и в продвижении, хорошо умеет кодить, не боится ООП, имеет понятие о сокрытии данных и работе с БД то лучше самописная цмска чем популярная в котрой известны все дыры