Приступая к созданию проекта, многие сталкиваются с дилеммой выбора движка. Будет ли он разрабатываться на какой-то полуготовой системе или писаться с нуля, зависит от многих факторов. Если вы программист, то скорее всего захотите писать с нуля на знакомом языке. Так на ваш взгляд проще, быстрее и эффективнее. Если вы нетехнический человек, или проект — всего лишь блог, вашим выбором может стать блоговый движок, который можно установить и настроить за пару часов.
Так или иначе, в самом начале проекта нужно понимать плюсы и минусы обоих подходов. Сегодня речь пойдет о том, почему я решил делать Giveaways.ru на Drupal и почему за полгода ни разу не пожалел об этом.
Поскольку начинал проект я в одиночку, а за плечами уже был опыт запуска нескольких проектов, я определил ряд критериев, которым должно было удовлетворять выбранное решение:
Drupal — не единственная CMS, с которой мне приходилось работать, но выбор остановился именно на этой системе. Возможно, она сложнее в освоении, чем другие и ее сообщество не так развито, как тот же WordPress, но потенциал Drupal превосходит известные мне CMS по своим возможностям для проектов с функционалом сложнее новостного портала или интернет-магазина.
Я решил запускать проект таким образом, чтобы несмотря на отсутствие полнофункциональной версии, на нем всегда можно было найти что-то полезное.
Так в самом начале я нарисовал и сверстал лендинг, который работал вместе с авторизацией через Инстаграм и собирал первых заинтересованных пользователей. На Drupal был написан простенький модуль авторизации и выложена первая страница.
Затем я решил запустить блог с полезными статьями по теме сервиса, чтобы как можно раньше появиться в поиске начать получать первый SEO-трафик. В Drupal уже встроена возможность вести блог со всеми фичами «из коробки», я просто добавил в меню Блог и начал писать статьи.
При разработке с нуля мне пришлось бы описывать программисту как должен работать блог, не забыть разные мелочи и все равно что-то могло быть упущено. Вот например, человекопонятные ссылки. С нуля нужно было, во-первых, не забыть про это, а во-вторых, подробно описать как это дело будет работать. А тут я просто установил модуль и нажал на пару кнопок.
В начале разработки идеи приходят и меняются с такой скоростью, что если бы их реализовывал только программист, проект развивался бы в разы медленнее, ведь я сам не могу написать ни строчки кода. Например, понадобилось мне добавить некий блок текста на определенную страницу, видимый только зарегистрированным пользователям, или подключить сервис Disqus для комментирования статей. 10 минут и готово. В эти 10 минут входит время на поиск в гугле инструкции как это сделать или модуля, который нужно установить и настроить.
В Drupal, благодаря модульной структуре практически нет проблем со взаимным использованием готовых модулей или разработок программиста. Часто при изменении требований достаточно просто отключить модуль или поменять где-то настройки. Разумеется, такой подход возможен, когда программист работает в идеологии Drupal, а не пишет какую-то свою приблуду, работающую «рядом» c Друпалом, а не внутри него.
И мне пришлось. Новый человек быстро вник в то, что было сделано и оперативно продолжил работу. По собственному опыту знаю, что на проектах, разрабатываемых с нуля это сложнее, ведь одни программисты не любят комментировать код, а другие не любят разбираться в чужом коде. К тому же у Drupal, как и у других CMS есть общепринятые подходы к разработке и сообщество, готовое прийти на помощь.
В Drupal, благодаря модульности, очень легко распараллелить потоки работ так, чтобы они никак не пересекались. Например, пока программист делал основной функционал проверки и загрузки Инстаграм-фоток в конкурсы, я настраивал прием платежей и правила списания с баланса за добавление всё тех же конкурсов.
На начальной стадии проекта тратить время на прорисовку всех страниц, различных состояний и элементов не хотелось, тем более, что понимание каким должен быть дизайн приходило постепенно. Поэтому я просто нашел и установил подходящий шаблон (тему) на Drupal, где большинство элементов уже были с каким-то базовым, вполне подходящим мне дизайном. Это позволило не тормозить запуск новых фич, дожидаясь макетов дизайна.
Drupal позволил быстро и с минимальными усилиями выпустить проект и проверить его бизнес-модель. Разумеется, в этой CMS есть и свои минусы, например, по словам программиста, плохо реализована работа с Cron и пришлось использовать сторонний. Кто-то ругается на производительность, но в мире масса высоконагруженных проектов на Drupal, а значит его нужно еще правильно «готовить».
Возможно, и в моем проекте найдется узкое место и когда-то придется все переписать заново, но уже сейчас можно сказать, что выбор был сделан не зря.
Так или иначе, в самом начале проекта нужно понимать плюсы и минусы обоих подходов. Сегодня речь пойдет о том, почему я решил делать Giveaways.ru на Drupal и почему за полгода ни разу не пожалел об этом.
Критерии выбора платформы
Поскольку начинал проект я в одиночку, а за плечами уже был опыт запуска нескольких проектов, я определил ряд критериев, которым должно было удовлетворять выбранное решение:
- Быстро развернуть базовый функционал
- Не лезть в код по каждой мелочи
- Формировать требования по ходу проекта, не боясь изменений
- С минимальными потерями сменить программиста, если придется
- Поручить разным людям несколько задач и не утонуть в багах
- Запуститься с минимальным дизайном
Drupal — не единственная CMS, с которой мне приходилось работать, но выбор остановился именно на этой системе. Возможно, она сложнее в освоении, чем другие и ее сообщество не так развито, как тот же WordPress, но потенциал Drupal превосходит известные мне CMS по своим возможностям для проектов с функционалом сложнее новостного портала или интернет-магазина.
Быстро развернуть базовый функционал
Я решил запускать проект таким образом, чтобы несмотря на отсутствие полнофункциональной версии, на нем всегда можно было найти что-то полезное.
Так в самом начале я нарисовал и сверстал лендинг, который работал вместе с авторизацией через Инстаграм и собирал первых заинтересованных пользователей. На Drupal был написан простенький модуль авторизации и выложена первая страница.
Затем я решил запустить блог с полезными статьями по теме сервиса, чтобы как можно раньше появиться в поиске начать получать первый SEO-трафик. В Drupal уже встроена возможность вести блог со всеми фичами «из коробки», я просто добавил в меню Блог и начал писать статьи.
При разработке с нуля мне пришлось бы описывать программисту как должен работать блог, не забыть разные мелочи и все равно что-то могло быть упущено. Вот например, человекопонятные ссылки. С нуля нужно было, во-первых, не забыть про это, а во-вторых, подробно описать как это дело будет работать. А тут я просто установил модуль и нажал на пару кнопок.
Не лезть в код по каждой мелочи
В начале разработки идеи приходят и меняются с такой скоростью, что если бы их реализовывал только программист, проект развивался бы в разы медленнее, ведь я сам не могу написать ни строчки кода. Например, понадобилось мне добавить некий блок текста на определенную страницу, видимый только зарегистрированным пользователям, или подключить сервис Disqus для комментирования статей. 10 минут и готово. В эти 10 минут входит время на поиск в гугле инструкции как это сделать или модуля, который нужно установить и настроить.
Формировать требования по ходу проекта, не боясь изменений
В Drupal, благодаря модульной структуре практически нет проблем со взаимным использованием готовых модулей или разработок программиста. Часто при изменении требований достаточно просто отключить модуль или поменять где-то настройки. Разумеется, такой подход возможен, когда программист работает в идеологии Drupal, а не пишет какую-то свою приблуду, работающую «рядом» c Друпалом, а не внутри него.
С минимальными потерями сменить программиста, если придется
И мне пришлось. Новый человек быстро вник в то, что было сделано и оперативно продолжил работу. По собственному опыту знаю, что на проектах, разрабатываемых с нуля это сложнее, ведь одни программисты не любят комментировать код, а другие не любят разбираться в чужом коде. К тому же у Drupal, как и у других CMS есть общепринятые подходы к разработке и сообщество, готовое прийти на помощь.
Поручить разным людям несколько задач и не утонуть в багах
В Drupal, благодаря модульности, очень легко распараллелить потоки работ так, чтобы они никак не пересекались. Например, пока программист делал основной функционал проверки и загрузки Инстаграм-фоток в конкурсы, я настраивал прием платежей и правила списания с баланса за добавление всё тех же конкурсов.
Запуститься с минимальным дизайном
На начальной стадии проекта тратить время на прорисовку всех страниц, различных состояний и элементов не хотелось, тем более, что понимание каким должен быть дизайн приходило постепенно. Поэтому я просто нашел и установил подходящий шаблон (тему) на Drupal, где большинство элементов уже были с каким-то базовым, вполне подходящим мне дизайном. Это позволило не тормозить запуск новых фич, дожидаясь макетов дизайна.
Вывод
Drupal позволил быстро и с минимальными усилиями выпустить проект и проверить его бизнес-модель. Разумеется, в этой CMS есть и свои минусы, например, по словам программиста, плохо реализована работа с Cron и пришлось использовать сторонний. Кто-то ругается на производительность, но в мире масса высоконагруженных проектов на Drupal, а значит его нужно еще правильно «готовить».
Возможно, и в моем проекте найдется узкое место и когда-то придется все переписать заново, но уже сейчас можно сказать, что выбор был сделан не зря.
