12 причин не использовать самописные CMS

Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим CMS. И этим «заболеванием» страдают 99% разработчиков сайтов — в какой-то момент, в порыве инфантильного максимализма программист, многие десятки часов проведший «в обнимку» с кодом какой-либо системы, восклицает — «Доколе! Сколько можно возиться с этим убожеством?! Я же знаю как сделать лучше!» и мало-помалу «я знаю!» превращается в твердую уверенность «я могу!» и вот уже, глядишь, строчка за строчкой начинает вырисовываться костяк нового детища.

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

Самописная система управления сайтом — платная или бесплатная CMS, написанная и поддерживаемая исключительно одним автором-разработчиком. Чаще всего такие системы предлагаются студиями веб-дизайна в качестве платформы для заказываемого сайта.

Кроме того, на рынке присутствуют и бесплатные самописные системы, разрабатываемые одиночками-энтузиастами.

Под понятием «самописная 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, который позволяет программистам разрабатывать на его основе сторонние приложения.

Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. Application Programming Interface, 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% больше, чем стоимость предыдущей разработки (не учитывая стоимость нового сайта), а в других — перенос приходилось осуществлять практически вручную, поскольку создавать систему импорта было просто нецелесообразно.

Подумайте, стоит ли оно того?

Самописная CMS для сайта — Как создать сайт

Часто владельцы создающих сайтов задаются вопросом: «Что лучше — самописная CMS или готовое решение?» Для начала надо понимать специфику самописных CMS, чем они отличаются от известных систем управления контентом.

Что лучше-самописная CMS или типовой движок?

Самописная CMS и её отличительные черты

Самописная CMS пишется в чистом коде, с нуля. Для этого используется один из языков веб-программирования. Прежде всего программируется необходимая функциональность. Самописный код легко меняется тем, кто его создал. Готовые решения, воплощённые в известных CMS (WordPress, Joomla, Drupal) ещё надо внимательно изучать. Не всем и не всегда они подойдут.

Преимущества самописной CMS

• Только необходимый функционал

Типовые движки имеют общую проблему — не весь их функционал используется. При этом забираются ресурсы и замедляется работа. В самописных движках только необходимый функционал. SEO-модули входят в него. Это намного упрощает работу. Ненужный функционал надо оптимизировать, а это забирает силы и время.

• Страницы грузятся быстро, работа стабильная

Новые функции внедрять легко — добавляется только самое необходимое. Лишнего кода нет, что положительно влияет на стабильность и скорость работы ресурса.

• Пользоваться просто и удобно

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

• Взломать такой сайт непросто

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

• Огромные дизайнерские возможности

Самописные CMS предоставляют дизайнерам широкие творческие возможности. Оформлять такие сайты можно как угодно — варианты ничем не ограничиваются.

• Обновление не требуется

Специалистам лишний раз вмешиваться не надо.

• Возможность брать лучшее из существующих движков

Это минимизирует недостатки сайта. Правда, доступно такое только классному специалисту. Недоучка не сможет взять лучшее из существующих движков и воплотить в самописном сайте.

Заключение

Для создания эксклюзивных проектов лучше создавать самописные CMS. Только они смогут воплотить нестандартный набор функций. В типовых CMS ещё нужно доводить до ума существующий функционал, а это дополнительные траты сил и времени.

Подробнее о том, как создавать сайты на CMS-системе и как подбирать CMS для сайта можно узнать на нашем бесплатном мастер-классе.

12 причин не использовать самописные CMS на сайте

Подробности

Просмотров: 13871

Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим CMS. И этим «заболеванием» страдают 99% разработчиков сайтов — в какой-то момент, в порыве инфантильного максимализма программист, многие десятки часов проведший «в обнимку» с кодом какой-либо системы, восклицает —«Доколе! Сколько можно возиться с этим убожеством?! Я же знаю как сделать лучше!» и мало-помалу «я знаю!» превращается в твердую уверенность «я могу!» и вот уже, глядишь, строчка за строчкой начинает вырисовываться костяк нового детища.

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

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

Самописная система управления сайтом — платная или бесплатная CMS, написанная и поддерживаемая исключительно одним автором-разработчиком. Чаще всего такие системы предлагаются студиями веб-дизайна в качестве платформы для заказываемого сайта.

Кроме того, на рынке присутствуют и бесплатные самописные системы, разрабатываемые одиночками-энтузиастами.
Под понятием «самописная CMS» подразумевается массовый продукт. Уникальные разработки, предназначенные для решения «одноразовых» нестандартных задач — в этой статье не рассматриваются.

1. Жесткая привязка к одному разработчику

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

Ситуация с самописными CMS выглядит абсолютно так же — приобретая или устанавливая самописную систему, клиент попадает в полную зависимости от ее разработчика, которая выражается в следующем:
все разработки, доработки и изменения CMS производятся только с помощью автора системы;
изменение ценовой политики или лицензии на использование CMS находится исключительно в сфере ответственности автора;
дальнейшее развитие системы или отказ от последующей разработки зависит исключительно от ее автора.

Говоря откровенно, автор системы может делать все, что ему заблагорассудится — закрывать разработку, продавать ее кому угодно, да хоть по примеру Одноклассников — ввести платные смс за регистрацию/скачивание дистрибутива/обновлений или встроить в последнее бесплатное обновление системы скрытый скрипт, скачивающий базу данных клиентов тех сайтов, чьи владельцы отказались платить за использование системы. Примеры, конечно, максималистские, но по факту автора практически ничто не ограничивает.

Пользователь же, наоборот — ограничен практически во всем и не может никоим образом влиять на политики лицензирования или же ценообразования. Даже в случае заключения договора на использование платной самописной CMS, учесть все пункты с одной стороны попросту невозможно, а с другой — сам автор не согласится на жестко регулирующие его деятельность пункты. В ситуации же с бесплатными CMS — система вообще поставляется под девизом «as is» — используете на свой страх и риск и за какие-либо возникшие в процессе эксплуатации ошибки или финансовые потери автор ответственности не несет.

2. Аудит безопасности

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

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

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

3. Малая распространенность системы

Практически все, даже самые ярые противники Open Source признают, что пользовательский аудит может в определенной степени заменить профессиональный аудит безопасности — тысячи программистов и разработчиков, ежедневно модифицирующих систему под нужды клиентов, рано или поздно найдут ту потенциальную угрозу, которая может существовать в системе и добавят ее в багтрекер для последующего исправления официальной командой разработчиков или даже больше — просто сами пришлют готовое решение.

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

4. Проработка системной архитектуры

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

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

по материалам Википедии

Учитывая, что заказчик обычно не способен оценить корректность архитектуры системы по причине закономерной недостаточности знаний в этой области, естественно этот вопрос остается на совести разработчика. Но как и в случае с безопасностью — вундеркинды встречаются крайне редко, а потому вопрос построения архитектуры самописной системы чаще всего раскрывается по методике — «не нужно изобретать велосипед». Разработчик берет за основу архитектуру одной из уже существующих популярных систем, вносит пару-тройку правок (но абсолютно не факт, что нужных и полезных) и говорит: «смотрите, моя новая архитектура революционна!».

5. Качество кода

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

6. Программистам для программистов

Давайте вспомним, почему Windows, при всей своей проблемности и ошибочности, до сих пор занимает лидирующее место среди операционных систем, используемых пользователями? По простой, в сущности, причине — она проста для освоения и не требует специфических знаний.

От многих пользователей я часто слышу — «административная часть Joomla для меня сложна, а я не хочу разбираться». А, в сущности, в ней нет ничего экстраординарного — ее интерфейс лишь немного отличается от привычных «деревоподобных» интерфейсов. Но для многих уже и это становится проблемой.

Итак, помимо того, что наш автор должен быть разработчиком, специалистом по безопасности и системным архитектором — кроме этого, он должен быть еще и специалистом по юзабилити.

7. Отсутствие полноценной пользовательской документации

Документация — ахиллесова пята любого программного обеспечения. Из всех CMS, с которыми я за свою практику имел дело, адекватные руководства пользователя были только лишь максимум у пяти процентов систем.

Остальные же 95%, в лучшем случае описывались разрозненными статьями на тему «Как сделать…» или же инструкциями уровня «нажмите левую кнопку мыши», а в худшем — просто ничем, предоставляя пользователю самостоятельно догадываться о назначении того или иного элемента «методом научного клика».

8. Отсутствие API

Почему Twitter в одночасье стал настолько популярен? Почему Yandex.Карты с некоторых пор можно встретить практически повсеместно? Ответ прост — полноценный API, который позволяет программистам разрабатывать на его основе сторонние приложения.

Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. Application Programming Interface, API [эй-пи-ай]) — набор готовых классов, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для её использования во внешних программных продуктах.

по материалам Википедии

И хотя API не является обязательным атрибутом CMS, его наличие ощутимо упрощает разработку сторонних приложений для сайта, таких как, например — связь с внутренними системами компании (SAP, SRM, модули электронной торговли и документооборота).

9. Проблема наличия лазеек

Разработчикам популярных Open Source или же проприетарных систем невыгодно оставлять какие-либо «черные ходы» по той простой причине, что в Open Souce системе они будут быстро найдены пользовательским сообществом, а в платных CMS с закрытым кодом — аудитом. Кроме того, если в отношении системы любого типа лицензирования хотя бы несколько раз будет поднят вопрос лазеек и будут приведены доказательства их наличия, то с популярностью и прибылью можно будет попрощаться раз и навсегда.

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

10. Отсутствие профессионального сообщества и службы поддержки

Популярные Open Source CMS хороши своими открытыми сообществами, в которых можно быстро найти ответ на большинство типовых задач. Поддержка проприетарных систем управления всегда обеспечивается службой поддержки и help desk. А к кому обращаться в случае использования самописной системы?

11. Отсутствие поддержки сторонних специалистов (бес- и платных)

Ок, давайте даже попробуем оставить в стороне глобальное понятие сообщества и определить — кто же может выступать в качестве хотя бы уж советчика в вопросах использования самописной системы? И снова — только сам ее автор. Банально — кому задать вопрос, если что-то не получается? Однако учитывая то — сколько уже профессий должен совмещать в себе этот человек, трудно себе представить наличие у него еще и способности заниматься одновременно разработкой и поддержкой большого количества пользователей.

12. Отсутствие профессиональных тестировщиков

Многие считают, что тестирование — довольно простое дело. Казалось бы, ну чего там — сел, прошелся по функциям системы, выписал ошибки и отдал программисту на исправление. Однако на практике все далеко не так просто. Я не буду детально останавливаться на методиках тестирования, интересующиеся могут почитать отдельную статью в Википедии, достаточно полно раскрывающую общие понятия и профессионального тестирования программного обеспечения.

13. Отсутствие четкого вектора монетизации или скрытый вектор (для бесплатных CMS)

Все мы прекрасно понимаем, что разработка CMS — дело сложное и отнимающее много времени, которое может быть потрачено на разработку оплачиваемых проектов. Соответственно, автор системы должен каким-то образом покрывать недополученную прибыль. Например, одним из таких способов является перевод системы на коммерческие рельсы.

Процесс выглядит так — начала пользователям предлагается система в качестве бесплатного ПО, но с определенной версии (чаще всего той, с которой система приобретает более-менее завершенный и полнофункциональный вид), автор заявляет, что отныне все обновления будут платными. То есть все те, кто уже успел поставить, настроить и подогнать под свои нужды систему могут или оставаться на старой версии, либо же платной получать обновления.

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

Второй же вариант развития событий выглядит и вовсе удручающе — автору в какой-то момент попросту надоедает заниматься не приносящей прибылью деятельностью или в его жизни что-то меняется и ему требуются дополнительные финансы (женитьба, рождение ребенка, постройка дома — мало ли что), но внутренние убеждения не позволяют принуждать пользователей платить за использование системы, а времени на ее разработку остается все меньше и меньше. А на donation долго не проживешь — наши реалии отличаются от западных. Закономерным итогом станет полное прекращение поддержки и в лучшем случае найдется тот, кто перехватит падающий «флаг» и продолжит разработку, а в худшем — система благополучно канет в лету.

Выводы

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

Из своей личной практики скажу, что уже несколько раз я сталкивался с самописными CMS с такой архитектурой, что перенос сайта на новую систему в одном случае стоил заказчику на 20% больше, чем стоимость предыдущей разработки (не учитывая стоимость нового сайта), а в других — перенос приходилось осуществлять практически вручную, поскольку создавать систему импорта было просто нецелесообразно.

Подумайте, стоит ли оно того?

Глеб Шапачников — Вебмастер.

Добавить комментарий

Бесплатные коробочные CMS или самописные CMS

Для каждого веб-сайта устанавливается система управления контентом, которая именуется CMS и расшифровывается как Content Manager System. Выбирать такую систему необходимо сразу же, перед созданием сайта и ответственность за этот выбор лежит не только на разработчике, но и на заказчике, который должен знать, что там ему такое собираются установить, чтобы в дальнейшем не проклинать весь мир за плохую работу веб-ресурса. При желании вы сможете поменять навязанный CMS на другую систему, но в результате все испортится, и надо будет создавать другой сайт, а это ну очень обидно, ведь снова придется платить. Существуют платные и бесплатные CMS, тут третьего не дано. В свою очередь платные делятся на два варианта – коробочные системы и самописные. А вот бесплатные CMS – это готовые решения, которые бывают только коробочными. Примеры таких популярных систем: 1C-Битрикс, Joomla!, Drupal, WordPress и так далее. Что такое коробочные CMS? Можно представить огромный ящик с кучей всего, что туда сложили разные программисты. Придумал один разработчик какую-нибудь функцию сайта, запечатал в коробочку, снабдил документацией, чтоб другие разобрались, и сложил в общий ящик и так далее. Использовать такую систему может любой разработчик, который занимается созданием сайтов. Самописные CMS кропотливо создают программисты какой-нибудь конкретной веб-студии, а потом ревностно хранят только для личного использования и ни с кем не делятся. И их можно понять, ведь это как уникальный рецепт бабушкиного пирога, который можно передать только по наследству в рамках одной семьи.

А теперь последует сравнительная характеристика. Бесплатные и платные CMS их плюсы, минусы и что лучше выбрать?

Техническая поддержка бесплатных CMS предлагает сотрудничество аж с двумя службами. Первая – это те разработчики, чей ящик с коробочками вы используете, а вторая – это тот программист, который создавал вам сайт с такой системой. Звучит впечатляюще, но на деле все труднее. Если у вас возникнет проблема, то ни одного из суперменов вы не увидите на горизонте. Разработчики CMS будут ссылаться на разработчиков сайта, а те, в свою очередь на первых. Этот замкнутый круг отнимет у вас много времени. И тут явный плюс в технической поддержке у разработчиков, которые создали вам сайт со своей самописной системой, ведь если что пойдет не так, вы будете знать, с кого спрашивать. Плюс, такой подход более внимательный и индивидуальный, если веб-студия, с которой вы сотрудничаете, подходит к вопросу разработки со всей ответственностью и предлагает грамотное составление договора. В таком случае у вас есть шанс в максимально короткие сроки избавиться от возникших неполадок.

Если вашему сайту необходимы уникальные решения, которые вы придумали и заснуть не можете спокойно, пока этого не будет на веб-ресурсе, то тут бесплатные системы не помогут. Такие решения пишутся отдельно разработчиками и в дальнейшем ими и поддерживаются. Еще один минус бесплатной CMS – это огромное количество документации, которая просто съедает кучу времени на разработку сайта. При использовании самописной системы такой волокиты нет, но если вам будет так необходимо снабдить себя документацией, для вас ее создадут.

Безопасность бесплатных CMS обещает нам быть выше, чем у самописных. Но что мы видим на выходе? Код CMS, разработанной в студии скрыт от всех, и его невозможно изучить, в то время как периодически появляется информация о новых слабых местах в коробочной системе. Управление самописной CMS – это ее огромный плюс. Все коробочные системы требуют определенных навыков и знаний, чтения документации и нервов, чтобы разобраться, как же наконец-то залить картинку на сайт. В это время квалифицированные программисты, создававшие самописную систему, позаботились о вас и сделали её максимально удобной и простой в использовании, позволяющей любому почувствовать себя настоящим контент менеджером. Все остальные факторы зависят уже от разработчика. Выбирая систему, обратите внимание на того, кто займется созданием сайта для вас. Даже следуя рецепту, любой торт легко можно испортить, если готовить его будет человек, умеющий только нарезать овощи на салат. 

← предыдущая следующая →

Сайт на CMS, фреймворке или собственная разработка — что лучше?. Читайте на Cossa.ru

Чего хочет заказчик, когда обращается в агентство? Чтобы ему сделали сайт. Каким образом — вопрос второстепенный. Главное, чтобы в бюджет уложились, всё работало как задумано, а идеально — ещё лучше. Как задумано — значит удобно для пользователей, легко в управлении и безопасно.

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

Все сайты делятся на два типа

• Созданные на CMS — системах управления сайтом (неважно, самописных, бесплатных или массовых коммерческих).

• Сайты, функциональность которых задаётся программистами. Специалисты могут использовать только языки программирования или работать с фреймворками.

Сайт состоит из внешней и внутренней части. Внешняя — это дизайн и контент, внутренняя — это база данных и административная панель. При разработке сайта на CMS необходимо создать только внешнюю часть — дизайн, сверстать его и «натянуть на движок». А при самостоятельной разработке придётся создавать и всю начинку.

Промежуточный вариант, который совмещает оба метода, — самописные системы управления контентом. В этом случае сначала с нуля создаётся скелет функций, а затем решение становится типовым, и уже на его основе создаются похожие сайты. Как правило, самописные CMS используются для решения довольно узких задач.

Проведём аналогию с автомобилем

• Собственная разработка — это создание машины с нуля, изобретение.

• Разработка на фреймворках — сборка машины с помощью готовых работающих узлов и запчастей.

• Сайт на самописных CMS — авторский автомобиль, который затем воспроизводится.

• Сайт на массовой CMS — универсальный серийный автомобиль промышленного производства.

По сути, мы видим переход от штучного продукта к рыночному, от индивидуального — к массовому производству. Причём у каждого варианта свои преимущества и недостатки.

Массовая CMS

Системы управления контентом, которые созданы компаниями-разработчиками, бывают как платными, так и бесплатными.

Бесплатные CMS ограничены по набору функций и технической поддержке, обычно используются для создания личных или небольших корпоративных сайтов. Нередко имеют проблемы с безопасностью, поэтому для создания серьёзных проектов не рассматриваются.

Коммерческие CMS — это мощные, универсальные системы для разработки разных типов сайтов с защитой и техподдержкой.

Когда подходит

• Вам не нужны специфические функции.
• Проект не предполагает высокой нагрузки.
• Ограниченный бюджет.
• Сжатые временные рамки.
• Нужен простой и понятный инструмент.

На массовой CMS можно создать все основные виды сайтов. Большинство систем состоит из модулей. Наборы таких модулей составляют редакции сайтов: корпоративный сайт, визитка, каталог, интернет-магазин, блог, портал и так далее. Это самый распространённый и простой способ сайтостроения.

Преимущества

• Легко изучить и настроить стандартный сайт. Не нужно знать языки программирования.

• Подключаемые модули. Можно расширять возможности за счёт плагинов.

• Быстрая скорость разработки. Основная часть работы уже сделана, от вас нужен контент, дизайн и настройка.

• Техническая поддержка. Компании-разработчики поддерживают собственные продукты.

• Полноценная документация. Для массовых коммерческих CMS легко найти всю сопутствующую документацию.

• Есть API. Готовые платформы имеют проработанный интерфейс прикладного программирования, который позволяет интегрировать ресурс с другими сервисами.

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

Недостатки

• Ограниченная функциональность. Как правило, у каждой CMS своя специализация, которую, впрочем, можно расширить за счёт редакций.

• Невысокая производительность. Это плата за универсальность. В движке заложены широкие возможности, что дополнительно нагружает сервера.

• Избыточность некоторых модулей. Бо́льшая часть возможностей может вообще не использоваться.

• Уязвимость. Поскольку основная масса коммерческих сайтов сделана на популярных коробочных версиях CMS, именно на них направлены атаки.

Самописная CMS

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

Если массовые CMS — это универсальные решения, то самописные версии — продукт индивидуальной разработки. Обычно заточены под решение конкретных задач.

Когда подходит

• Готовые решения вам однозначно не подходят.
• Вы уверены в разработчике самописного движка.
• У вас есть время и деньги на разработку.

Самописные CMS чаще используют для специфических проектов, когда требуется повышенный уровень безопасности, гибкость или, наоборот, простота в работе. Примером могут служить движки, разработанные для онлайн-СМИ. Они лишены громоздкости массовых систем и при этом могут обладать функциями управления контентом, которых нет в обычных движках.

Такие CMS очень кастомизированные. Как правило, обладают специальным интерфейсом, который удобен для редакторской работы. В этом случае переделка обычной CMS обошлась бы дороже и велась бы дольше, нежели собственная разработка.

Преимущества

• Можно продумать функции сайта под конкретный проект.

• Нет плагинов и расширений, которые требуют обслуживания и утяжеляют сайт.

• Ниже вероятность взлома, исходный код будет только у вас и разработчика.

• Выше производительность, поскольку нет лишнего кода.

• Проще управление — можно включить только те элементы, которые вам необходимы.

Недостатки

• Привязка к конкретному разработчику. Все обновления и техподдержку придётся проводить через него.

• Высокая стоимость проекта. Придётся оплачивать услуги опытных программистов или студию.

• Качество продукта полностью зависит от квалификации исполнителя, а грамотных и опытных профессионалов найти сложно.

• Зачастую нет полноценной документации, поскольку проекты изначально строятся под заказ и не рассчитаны на массовое использование.

• Сложности с технической поддержкой. Если исполнитель вдруг пропадёт, вы столкнётесь с большими проблемами.

• Нет API. Для любой интеграции придётся создавать уникальные решения, что выльется в затраты времени и финансов.

Разработка на фреймворках

В переводе с английского framework — каркас, остов, структура. В разработке это готовая надстройка над «чистым» языком программирования. Фреймворк выполняет две задачи: задаёт архитектуру и позволяет подключать дополнительные модули и пакеты, за счёт чего можно расширять функциональность проекта.

Фреймворк — это набор отлаженного кода для решения конкретных задач, которые чаще всего стоят перед разработчиками. Если при разработке на CMS вы отрезаете все лишнее, то здесь всё наоборот: «лепите» сами из готовых блоков. Во многих случаях такой подход является более эффективным и оправданным.

На основе фреймворков можно разработать отдельное веб-приложение, сайт и даже CMS. Фреймворки существуют для всех языков программирования, бывают самописными и студийными. Наиболее популярные представители: Yii, Zend Framework, Symfony2, Laravel, Phalcon, Codeigniter, Kohana.

Когда подходит

• Проект с высокой нагрузкой — когда производительность сайта критически важна.

• Необычный, нешаблонный проект. Тот случай, когда лучше создавать что-то самому, чем переделывать.

• Проект будет активно изменяться и подстраиваться под тренды и ваши потребности.

• У вас, как у заказчика, достаточно опыта и есть чёткое понимание, каким должен быть проект и его особенности.

Разработка на фреймворках сложнее, чем на CMS, и требует высокой квалификации как от разработчиков, так и от заказчика. Необходимо подобрать специалиста, оценить его опыт и чётко поставить перед ним задачи. Гибкость разработки на фреймворках открывает массу возможностей, но между тем приносит определённые сложности.

Преимущества

• Высокая производительность. Меньше лишних элементов — быстрее работа.

• Большая степень индивидуализации для решения конкретных задач.

• Отлаженный код и безопасность. Фреймворки постоянно тестируют на ошибки.

• Гибкость. Можно легко решать даже нестандартные задачи, при этом разными путями.

• Доступность дополнений. Можно использовать в работе готовые пакеты и библиотеки.

Недостатки

• Сложность — разработчику необходимо обладать высокой квалификацией.

• Нет административной части — раздел редактирования нужно создавать самостоятельно.

• Нужно много времени — сроки значительно увеличиваются.

• Высокая стоимость разработки.

• Дорогое обслуживание. Развитие сайта также будет стоить дороже, поскольку каждый раз придётся привлекать специалистов.

Собственная разработка

Под собственной разработкой понимается создание сайтов на языках программирования, например, на чистом HTML или PHP. При этом вся функциональность прорабатывается с нуля.

Когда подходит

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

• Сайт должен стать конкурентной фишкой компании. Если вы хотите внедрить на сайт уникальную и сложную функциональность. Например, у вас интернет-магазин: чтобы отличаться от конкурентов, вы планируете внедрить поиск товара по картинке или ссылке. Или хотите удивить пользователей тем, что они могут покупать товары с помощью голосового интерфейса.

Преимущества

• Вы получите набор функций, о котором пожелаете.
• Высокая производительность.
• Полный контроль разработки.
• Свобода творчества — вы ограничены только возможностями языка разработки.

Недостатки

• Большие временные затраты.
• Требуется высокая квалификация и опыт разработчиков, поскольку им придётся создавать все с нуля.
• Нужен большой бюджет.

Чтобы владеть чем-то уникальным, нужно вложить много ресурсов. Без команды опытных программистов — никуда.

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

Хорошо, если у вас есть бюджет на агентство. Однако в последнем случае процесс становится не столь гибким. К тому же агентств, которые готовы взяться за создание «велосипеда», на рынке не так много.

Лидеры рунета всё делают сами

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

Похожая ситуация с крупнейшими сайтами рунета — из топ-100 подавляющее большинство работает либо на самописных CMS, либо разработаны на фреймворках или языках программирования.

Лидеры рынка — это всегда высоконагруженные, нестандартные проекты с уникальной начинкой. Ещё один важный нюанс: большинству крупных сайтов уже много лет, и на момент их создания не было достаточно продвинутых массовых CMS.

Но это не значит, что массовые CMS проигрывают

Во-первых, подавляющее большинство сайтов — а их миллионы — всё же работают на CMS. Во-вторых, ещё недавно собственная CMS была у каждой студии. Даже мы в Uplab создавали собственную CMS, но по ряду рациональных причин перешли на Битрикс.

Мы уверены, что сделали верный выбор. Поддержка собственной CMS отнимала много сил, а результат не всегда радовал. Битрикс продолжает набирать обороты и сейчас занимает верхние строчки в рейтинге CMS Magazine.

Какой бы метод вы ни выбрали, делайте это осознанно, тщательно оценив риски, сроки и бюджет.

Читайте также:

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на [email protected]. А наши требования к ним — вот тут.

Сайт на CMS, фреймворке или собственная разработка — что лучше?. Читайте на Cossa.ru

Чего хочет заказчик, когда обращается в агентство? Чтобы ему сделали сайт. Каким образом — вопрос второстепенный. Главное, чтобы в бюджет уложились, всё работало как задумано, а идеально — ещё лучше. Как задумано — значит удобно для пользователей, легко в управлении и безопасно.

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

Все сайты делятся на два типа

• Созданные на CMS — системах управления сайтом (неважно, самописных, бесплатных или массовых коммерческих).

• Сайты, функциональность которых задаётся программистами. Специалисты могут использовать только языки программирования или работать с фреймворками.

Сайт состоит из внешней и внутренней части. Внешняя — это дизайн и контент, внутренняя — это база данных и административная панель. При разработке сайта на CMS необходимо создать только внешнюю часть — дизайн, сверстать его и «натянуть на движок». А при самостоятельной разработке придётся создавать и всю начинку.

Промежуточный вариант, который совмещает оба метода, — самописные системы управления контентом. В этом случае сначала с нуля создаётся скелет функций, а затем решение становится типовым, и уже на его основе создаются похожие сайты. Как правило, самописные CMS используются для решения довольно узких задач.

Проведём аналогию с автомобилем

• Собственная разработка — это создание машины с нуля, изобретение.

• Разработка на фреймворках — сборка машины с помощью готовых работающих узлов и запчастей.

• Сайт на самописных CMS — авторский автомобиль, который затем воспроизводится.

• Сайт на массовой CMS — универсальный серийный автомобиль промышленного производства.

По сути, мы видим переход от штучного продукта к рыночному, от индивидуального — к массовому производству. Причём у каждого варианта свои преимущества и недостатки.

Массовая CMS

Системы управления контентом, которые созданы компаниями-разработчиками, бывают как платными, так и бесплатными.

Бесплатные CMS ограничены по набору функций и технической поддержке, обычно используются для создания личных или небольших корпоративных сайтов. Нередко имеют проблемы с безопасностью, поэтому для создания серьёзных проектов не рассматриваются.

Коммерческие CMS — это мощные, универсальные системы для разработки разных типов сайтов с защитой и техподдержкой.

Когда подходит

• Вам не нужны специфические функции.
• Проект не предполагает высокой нагрузки.
• Ограниченный бюджет.
• Сжатые временные рамки.
• Нужен простой и понятный инструмент.

На массовой CMS можно создать все основные виды сайтов. Большинство систем состоит из модулей. Наборы таких модулей составляют редакции сайтов: корпоративный сайт, визитка, каталог, интернет-магазин, блог, портал и так далее. Это самый распространённый и простой способ сайтостроения.

Преимущества

• Легко изучить и настроить стандартный сайт. Не нужно знать языки программирования.

• Подключаемые модули. Можно расширять возможности за счёт плагинов.

• Быстрая скорость разработки. Основная часть работы уже сделана, от вас нужен контент, дизайн и настройка.

• Техническая поддержка. Компании-разработчики поддерживают собственные продукты.

• Полноценная документация. Для массовых коммерческих CMS легко найти всю сопутствующую документацию.

• Есть API. Готовые платформы имеют проработанный интерфейс прикладного программирования, который позволяет интегрировать ресурс с другими сервисами.

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

Недостатки

• Ограниченная функциональность. Как правило, у каждой CMS своя специализация, которую, впрочем, можно расширить за счёт редакций.

• Невысокая производительность. Это плата за универсальность. В движке заложены широкие возможности, что дополнительно нагружает сервера.

• Избыточность некоторых модулей. Бо́льшая часть возможностей может вообще не использоваться.

• Уязвимость. Поскольку основная масса коммерческих сайтов сделана на популярных коробочных версиях CMS, именно на них направлены атаки.

Самописная CMS

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

Если массовые CMS — это универсальные решения, то самописные версии — продукт индивидуальной разработки. Обычно заточены под решение конкретных задач.

Когда подходит

• Готовые решения вам однозначно не подходят.
• Вы уверены в разработчике самописного движка.
• У вас есть время и деньги на разработку.

Самописные CMS чаще используют для специфических проектов, когда требуется повышенный уровень безопасности, гибкость или, наоборот, простота в работе. Примером могут служить движки, разработанные для онлайн-СМИ. Они лишены громоздкости массовых систем и при этом могут обладать функциями управления контентом, которых нет в обычных движках.

Такие CMS очень кастомизированные. Как правило, обладают специальным интерфейсом, который удобен для редакторской работы. В этом случае переделка обычной CMS обошлась бы дороже и велась бы дольше, нежели собственная разработка.

Преимущества

• Можно продумать функции сайта под конкретный проект.

• Нет плагинов и расширений, которые требуют обслуживания и утяжеляют сайт.

• Ниже вероятность взлома, исходный код будет только у вас и разработчика.

• Выше производительность, поскольку нет лишнего кода.

• Проще управление — можно включить только те элементы, которые вам необходимы.

Недостатки

• Привязка к конкретному разработчику. Все обновления и техподдержку придётся проводить через него.

• Высокая стоимость проекта. Придётся оплачивать услуги опытных программистов или студию.

• Качество продукта полностью зависит от квалификации исполнителя, а грамотных и опытных профессионалов найти сложно.

• Зачастую нет полноценной документации, поскольку проекты изначально строятся под заказ и не рассчитаны на массовое использование.

• Сложности с технической поддержкой. Если исполнитель вдруг пропадёт, вы столкнётесь с большими проблемами.

• Нет API. Для любой интеграции придётся создавать уникальные решения, что выльется в затраты времени и финансов.

Разработка на фреймворках

В переводе с английского framework — каркас, остов, структура. В разработке это готовая надстройка над «чистым» языком программирования. Фреймворк выполняет две задачи: задаёт архитектуру и позволяет подключать дополнительные модули и пакеты, за счёт чего можно расширять функциональность проекта.

Фреймворк — это набор отлаженного кода для решения конкретных задач, которые чаще всего стоят перед разработчиками. Если при разработке на CMS вы отрезаете все лишнее, то здесь всё наоборот: «лепите» сами из готовых блоков. Во многих случаях такой подход является более эффективным и оправданным.

На основе фреймворков можно разработать отдельное веб-приложение, сайт и даже CMS. Фреймворки существуют для всех языков программирования, бывают самописными и студийными. Наиболее популярные представители: Yii, Zend Framework, Symfony2, Laravel, Phalcon, Codeigniter, Kohana.

Когда подходит

• Проект с высокой нагрузкой — когда производительность сайта критически важна.

• Необычный, нешаблонный проект. Тот случай, когда лучше создавать что-то самому, чем переделывать.

• Проект будет активно изменяться и подстраиваться под тренды и ваши потребности.

• У вас, как у заказчика, достаточно опыта и есть чёткое понимание, каким должен быть проект и его особенности.

Разработка на фреймворках сложнее, чем на CMS, и требует высокой квалификации как от разработчиков, так и от заказчика. Необходимо подобрать специалиста, оценить его опыт и чётко поставить перед ним задачи. Гибкость разработки на фреймворках открывает массу возможностей, но между тем приносит определённые сложности.

Преимущества

• Высокая производительность. Меньше лишних элементов — быстрее работа.

• Большая степень индивидуализации для решения конкретных задач.

• Отлаженный код и безопасность. Фреймворки постоянно тестируют на ошибки.

• Гибкость. Можно легко решать даже нестандартные задачи, при этом разными путями.

• Доступность дополнений. Можно использовать в работе готовые пакеты и библиотеки.

Недостатки

• Сложность — разработчику необходимо обладать высокой квалификацией.

• Нет административной части — раздел редактирования нужно создавать самостоятельно.

• Нужно много времени — сроки значительно увеличиваются.

• Высокая стоимость разработки.

• Дорогое обслуживание. Развитие сайта также будет стоить дороже, поскольку каждый раз придётся привлекать специалистов.

Собственная разработка

Под собственной разработкой понимается создание сайтов на языках программирования, например, на чистом HTML или PHP. При этом вся функциональность прорабатывается с нуля.

Когда подходит

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

• Сайт должен стать конкурентной фишкой компании. Если вы хотите внедрить на сайт уникальную и сложную функциональность. Например, у вас интернет-магазин: чтобы отличаться от конкурентов, вы планируете внедрить поиск товара по картинке или ссылке. Или хотите удивить пользователей тем, что они могут покупать товары с помощью голосового интерфейса.

Преимущества

• Вы получите набор функций, о котором пожелаете.
• Высокая производительность.
• Полный контроль разработки.
• Свобода творчества — вы ограничены только возможностями языка разработки.

Недостатки

• Большие временные затраты.
• Требуется высокая квалификация и опыт разработчиков, поскольку им придётся создавать все с нуля.
• Нужен большой бюджет.

Чтобы владеть чем-то уникальным, нужно вложить много ресурсов. Без команды опытных программистов — никуда.

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

Хорошо, если у вас есть бюджет на агентство. Однако в последнем случае процесс становится не столь гибким. К тому же агентств, которые готовы взяться за создание «велосипеда», на рынке не так много.

Лидеры рунета всё делают сами

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

Похожая ситуация с крупнейшими сайтами рунета — из топ-100 подавляющее большинство работает либо на самописных CMS, либо разработаны на фреймворках или языках программирования.

Лидеры рынка — это всегда высоконагруженные, нестандартные проекты с уникальной начинкой. Ещё один важный нюанс: большинству крупных сайтов уже много лет, и на момент их создания не было достаточно продвинутых массовых CMS.

Но это не значит, что массовые CMS проигрывают

Во-первых, подавляющее большинство сайтов — а их миллионы — всё же работают на CMS. Во-вторых, ещё недавно собственная CMS была у каждой студии. Даже мы в Uplab создавали собственную CMS, но по ряду рациональных причин перешли на Битрикс.

Мы уверены, что сделали верный выбор. Поддержка собственной CMS отнимала много сил, а результат не всегда радовал. Битрикс продолжает набирать обороты и сейчас занимает верхние строчки в рейтинге CMS Magazine.

Какой бы метод вы ни выбрали, делайте это осознанно, тщательно оценив риски, сроки и бюджет.

Читайте также:

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на [email protected]. А наши требования к ним — вот тут.

Выбираем сайт IT компании: самописный или на основе коробочной CMS?

Сооснователь Kraftblick

 

Пост навеян общением с рядом собственников IT компаний, да и просто просмотром сайтов этих компаний.

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

Таким образом, компании создают сайты либо на основе каких-нибудь левых фреймворков или, прости Господи, выкладывают сайты чуть ли не на HTML.

Итоговый результат выглядит примерно так. (Источник: rate1.com.ua)

Давайте поговорим о том, насколько это целесообразно и целесообразно ли вообще.

Несколько аргументов в сторону самописного сайта

На самом деле, аргументов нет. Вообще. Кроме тех случаев, когда вы понимаете что и зачем вы делаете.

Если владельцы планируют хоть как-то развивать сайт и проводить с ним какие-либо маркетинговые активности, то делать самописный сайт это самое плохое, что можно придумать.

Чем плохи самописные сайты?

Самописный сайт отнимает много усилий и времени команды, а это время, например, можно использовать для поиска клиентов и оказания им услуг. Вместо этого, некоторые тратят драгоценные минуты, часы и дни на создание каких-то страниц из ”говнопалок” и кривого кода.

Просто представьте, что ваш программист несколько дней тратит по 20 часов на попытки создать из вашего сайта что-то подобающее.

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

Вот как вы будете выглядеть, отказавшись от самописного сайта. (Источник: pikabu.ru)

В этом отношении, с готовыми CMS системами всё гораздо проще. На работу с ними готовы очень многие разработчики – фрилансеры, да и хватает просто стандартизированных услуг от владельцев платформ.

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

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

Когда вы выбираете разработку самописного сайта, вы радуете дедушку Леопольда фон Захер-Мазоха. (Источник: austria-today.ru)

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

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

🎄Приходите к нам на IT митапы Firstner в январе 2020!🎄

 

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

Апогеем была история о том, как при необходимости поменять простой текст на каком-то самописном сайте нужно было его коммитить. Это просто неприемлемо, если вы хотите проводить какие-нибудь маркетинговые активности.

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

Например, сайт Oxagile. У Oxagile сайт работает на CMS WordPress.

Вот как выглядит их сайт. (Источник: oxagile.com)

У Itransition сайт на друпале.

Вот как выглядит сайт Itransition. (Источник: itransition.com)

Если даже такие компании посчитали целесообразным использовать CMS-ки, то какие могут быть причины у более маленькой компании или студии с десятком человек городить свой собственный огород и изобретать велосипед?

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

Делать нужно следующее: если сайта у вас нет, а есть только лэндинг, и вы собираетесь заменить его нормальным сайтом, то даже не думайте в пользу того, чтобы сделать его самописным. Лучше используйте стандартную CMS систему.

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

Но если у вас есть сайт, и вы планируете проводить маркетинговые активности, бегите от самописности как от огня и переводите сайт на нормальную CMS.

Вот лишь малая толика CMS систем, из которых вы можете выбрать свою. (Источник: elbuz.com)

Мы в свою очередь можем порекомендовать WordPress. По нашему опыту, здесь есть несколько действительно важных и крутых штук:

1. Для WordPress есть всё, что только можно представить в виде плагинов, платных или бесплатных.

Т.е. вы настолько лишены необходимости в каком-то кодинге, что радости нет предела.

2. Кроме того, для WordPress есть огромное количество дизайнов в виде тем.

Темы можно качать, например, на ThemeForest, там они стоят примерно по 60 баксов, есть даже более дешевые варианты.

Просто откройте некоторые из них и посмотрите, во сколько бы вам обошлось создание подобного сайта.

Например, эта тема в момент написания статьи стоила $39. (Источник: themeforest.net)

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

3. Для WordPress легко и очень дешево находить помощников, фрилансеров, которым можно аутсорсить большую часть работ

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

4. Значительную часть функционала можно расширять настройкой плагинов, которые не требуют программирования вообще

То же реально делать с помощью каких-то разовых работ, на которые можно нанимать людей за 5-10 баксов на таких площадках, как Fiverr или Upwork.

В итоге

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

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

Выберите для себя наиболее подходящую CMS систему и не дурите себе голову (мы в Kraftblick, например, используем WordPress).