12 причин не использовать самописные CMS
08-01-2010 | Автор: Yaroslav.CH | Просмотров: 2,542
Рубрика: Система управления сайтом (CMS)
Метки: Заказчику
74
Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим 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% больше, чем стоимость предыдущей разработки (не учитывая стоимость нового сайта), а в других — перенос приходилось осуществлять практически вручную, поскольку создавать систему импорта было просто нецелесообразно.
Подумайте, стоит ли оно того?
И да и нет. Так как можно каждый пункт выполнить правильно :) Google делали два человека Сергей Брин и Лари Пейдж, WordPress вообще студент делал, а MyYear Book делали дети 15 лет(брат и сестра) ))
Конечно они все эти системы которые мы видим сейчас не сделали сами и досих пор не делают сами. Они собрали команду со временем :) Но первые значительные строчки написали они :)
Awilum, соглашусь, но приведенные примеры — скорее исключение из правил и тут есть свои ремарки — Брин с Пейджем делали не столько Google как таковой, сколько именно алгоритм поиска; WordPress делался уже не тем студентом, который делал b2/cafelog; а в MyYear Book — дети были, насколько я помню, только авторами идеи :)
Но, к сожалению, в массе своей — разработчики самописных CMS никак не относятся к этой когорте и те поделки, которые получаются — совсем не похожи на перечисленные системы, а те «первые значительные строки» настолько кривы, что с самого начала получаются просто гомункулусы :)
Хорошо! Я согласен с Вашими выводами,но что конкретно хотите предложить?
© Yaroslav.Ch я соглашусь конечно с тем, что большинство считают себя революционерами мира и делают свою систему чего либо, что перевернуть мир, но выходит это у единиц... А какая польза от этих велосипедов ? Опыт... может они и пишут свою CMS хоть она и не станет убийцей друпала но опыт разработки подобных систем получить можно :) Программист(веб) должен написать свой шаблонизатор,фреймфорк и CMS :)
Сам ответил и убил все вышеуказанные аргументы :-)
Все зависит от цели, постановки задачи и преследуемой идеи. Если идея банальна и автор изобретает велосипед (кстати, тут давеча очередной изобрели donbass.ua/news/technolog...vpolne-foto.html) — дело не возможно подпадает под изложенное выше. А если, как правильно сослался первый комментатор, автор делает что-то действительно новое и своё, то о не самописной системе и речи быть не может.
Приведу живой пример на себе: я не являюсь программистом, но примерно осенью 2003 года захотел сделать свою интернет-страничку. В которой хочу публиковать фотографии и небольшие рассказики, плюс дать возможность посетителям оставлять комментарии (ничего не напоминает? :-) ).
Да, и я написал свой движок. С информацией, админкой и т.п.
Не идеально, но как потом выяснилось — я двигался в том же направлении, куда потом бросился весь интернет.
Т.е. смысл делать уже есть. Теперь осталось ответить себе на вопрос — а вдруг кому-то еще нужно именно такое решение? Без особых требований к безопасности, требованиям по памяти и т.п.? Именно такое: простое и работающее. Не требующее многих дней на сравнения, работу с сотнями форумов в сетях, разворачиванием дополнительных тестовых площадок для сравнений и т.п.
Вот и получается, что самописное имеет право жить и смысл в них весьма и весьма не малый. И причин _использовать_ самописные системы может оказаться 120 или даже 1200.
Воспользоваться самописным CMS можно если быть уверенным на все сто процентов. Я отдаю предпочтение команде спецов программистов, нежели одному самоучке. Хотя и среди самоучек есть гении.
Иван, предложение очень простое — не использовать самописные CMS и не соглашаться на предложение их применения для разрабатываемых сайтов (личных и коммерческих). Существует масса как платных, так и бесплатных систем, хорошо себя зарекомендовавших по всем 12 изложенным выше пунктам.
Чуть позже я опубликую статью о критериях выбора CMS, в зависимости от задач, которые ставятся перед сайтом. Если Вы еще не являетесь подписчиком — пожалуйста, подпишитесь на RSS или на рассылку по почте, и Вам обязательно придет уведомление.
Awilum, а вот тут соглашусь, но с одной корректировкой — программист должен написать ее для себя и не предлагать ее другим пользователям до тех пор, пока не будет уверен в том, что его система действительно чего-то стоит и кроме того, он готов заниматься ее развитием и вкладываться в нее.
А в противном случае — можно ограничиться использованием на своих личных проектах уровня дневников и блогов.
Основная проблема в том, что львиная доля эти гомункулусов сразу выбрасывается в свет и, более того, начинает предлагаться пользователям (как платно, так и бесплатно).
Я не говорю, что нужно замереть в развитии и ничего не делать, я утверждаю только то, что до того как ты не уверен в адекватности своей разработки — не нужно тащить ее в мир.
Vovas,
Отнюдь, ни малейшего противоречия — видишь ли, Брин и Пейдж существуют в единственном экземпляре — и стали успешны не потому, что когда-то вовремя написали кусок кривого кода. Перед этим товарищи много и упорно учились и думали, а только уже потом принесли то, что хотели сделать — другим.
Согласился бы, если бы ты мне показал хотя бы одну успешную самописную CMS, с по-настоящему оригинальными и инновационными решениями.
Ну и, ты стал продавать его (как ты сам говоришь — неидеальный, незаконченный, с уровнем кода не выше среднего) хоть одному клиенту? Или ты активно стал его пиарить по «интернетам» с предложением использовать? Ведь нет, правильно? Ты написал его исключительно для себя и сам же его и использовал.
Тут вопрос не в том — нужно разрабатывать или нет, важен момент камерности или публичности, а кроме того ответственности.
А вдруг не нужно? Давай лучше ответим себе на другой вопрос — а сколько клиентов (а вместе с ними и админов) напоролось на вот такие поделки, которые потом пришлось выбрасывать и переделывать заново? А напоролось только потому, что кто-то в свое время решил, что нужно использовать как раз вот такое «без изысков».
А сколько хотя бы даже банальных баз данных с почтовыми адресами юзеров уплыло в руки спамеров через вот такие «без особых требований к безопасности»?
А сколько контор попало на необходимости переносить сайты с даже более-менее нормальной самописной системы только потому, что разработчик «откинул коньки»?
Вот и вопрос — чего ради использовать то, что заведомо не соответствует нужному уровню?
Только как правильно заметил Awilum — в качестве тестовых площадок для оттачивания программистом своего умения и мастерства. Не больше.
Rostislav., честно говоря, я не очень себе представляю, какие действия нужно произвести, чтобы быть уверенным в чужом самописном на 100%. Разве что отдать его на аудит специалисту действительно высокого уровня или же получить его от такого специалиста, после чего перепроверить у еще одного.
Правда не совсем ясно — какой смысл в этом действии.
Вы правы — действительно бывают, но по сравнению с количеством поделок на рынке, они явно проигрывают в числе.
Полностью согласен — вот как раз использование команды специалистов, включающую в себя экспертов разной спецификации и может дать полноценный и качественный результат на выходе.