Drupal. Проблемы и достижения

With Drupal, features are Cheap. Details are Expensive.

Vesa Palmu, CEO компании Wunderkraut

Мысли на этот пост всё никак не собирались в слова, пока совершенно случайно в короткий промежуток времени мне не пришлось вести одну и ту же дискуссию с совершенно разными людьми, а это хороший знак того, что время пришло. К тому же на Reddit, Google+, и канале #drupal на Freenode были очень похожие споры, из которых удалось кое что вынести. Думаю, будет полезно как business people, так и разработчикам.

Invented here

Я уже видел это модуль

Начнем с того, что напомним себе про философию «Not invented here» (NIH), в переводе «Не изобретено здесь», которую исповедуют некоторые компании и которая заключается в полном или частичном игнорировании инноваций, не изобретённых внутри самой компании. Простыми словами, даже если технология уже обкатана на сто процентов, компания принимает решение о самостоятельной её разработке in-house, считая, что так будет дешевле, безопаснее и надёжнее. Представим себе ситуацию с некоторыми сервисами Google, которые имеют привычку неожиданно закрываться или кардинально преображаться, и NIH уже не покажется такой наивной.

Противоположностью NIH является «Invented Here» («Уже Изобретено» или «Изобретено Здесь»), которая последние несколько лет являлась одним из столпов, сильнейших преимуществ Drupal, и в то же время одной из его серьёзнейших проблем.

С позиции разработчика

Очень много модулей

Возьмём, к примеру, стиль мышления начинающего или чуть более опытного Drupal девелопера, или на этот момент лучше назовём его «создатель сайтов». Его задача — сделать простейшую форму опроса с несколькими полями. Нет проблем — ставим Webform, накликиваем нужные поля и задача решена. Неожиданно возникает необходимость валидации. Ставим модуль Webform Validation. Клиент решает, что списки и чекбоксы выглядят слишком стандартно. Ставим Options Element. Экспорт в PDF — Webform2PDF. Добавить модный jQuery Accordion эффект на группы полей — Webform Accordion. Проверять емэйл адрес отправителя — Webform Confirm Email Address. И так далее...

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

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

Вот и приехали. Модуль Webform Confirm Email Address позволяет включить и выключить валидацию глобально, и ничего похожего на нашу задачу в нём нет. И вот наш среднестатический начинающий друпалер начинает постигать т.н. «тёмную сторону Drupal». Даже если PHP не проблема, это не избавит его от постигания логики Webform Confirm Email Address, который может быть написан не по стандартам, вникания в особенности его интеграции с «родителем» Webform, и затем, если уж делать всё по уму, написания своего модуля для решения поставленной задачи. И это не учитывая того, что Webform вообще-то довольно изолированный от экосистемы и API Друпала модуль, что внесёт ещё большую неразбериху.

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

И в этом главная проблема — мы настолько привыкли к слогану «there is a module for that», что перестали задумываться о самом главном — качестве кода нашего приложения, мы не думаем о приложении как о целостном объекте, который должен обладать гибкостью, расширяемостью, стабильностью, а вместо этого воспринимаем сайт как набор накачанных с drupal.org модулей, каждый из которых живёт своей жизнью, и нас совершенно не волнует, какой именно. До тех пор, пока не происходит катастрофа, разумеется.

История выше это просто пример, взятый из головы, поэтому готового решения проблемы я не предложу, но как только стало ясно, что форма будет расширяться до бесконечности, стоило подумать о прекращении порочной практики докидывания новых модулей и сконцентрироваться на расширяемости решения — многие задачи можно сделать на Rules API и чуть-чуть PHP, где-то пришлось бы полностью дописать свою логику, может быть стоило даже отказаться от устаревшего Webform в пользу Entityforms, который по крайней мере использует стандартный API, а значит и всю остальную логику к нему дописать гораздо проще.

Ещё один пример — breadcrumbs, или «хлебные крошки». Для управления ими есть миллион модулей — Hansel, Custom Breadcrumbs, Menu Breadcrumb, Crumbs и т.д., но большинство проблем решается через drupal_set_breadcrumb() в hook_node_view() и hook_taxonomy_term_view() и логикой, которую можно просто скопировать с того же dropbucket.org в большинстве случаев.

Сильная сторона Drupal

Со времени появления Drupal 7 не тысячи готовых модулей являются сильной стороной Drupal (в отличие от Wordpress), а мощные и гибкие API, которые позволяют решать самые сложные задачи, приложив минимум усилий. Но всё же усилий больше, чем установка и настройка модулей, поэтому так много из нас до сих пор мыслят устаревшими категориями.

У нас есть Field API, Forms API, Entity API, Database API на PDO, и будет ещё больше в Drupal 8, поэтому всё нытьё о том, что Drupal уже не тот можно отнести к обычной человеческой лени.

Rails, Django, Symfony и другие системы безусловно круты, но некоторых вещей в них не было и не будет.

Не поймите неправильно, я не считаю, что «накликивание» функционала это плохо. Зачем мучаться с запросами в базу, если простые списки легко сделать на Views и уже затем дописать их до нужного состояния. Или за полчаса сделать полноценный RESTful API. Или иметь возможность проектировать типы контента с кастомными полями прямо в интерфейсе системы. Или парсить большие датасеты XML, JSON и CSV и конвертировать их в Drupal объекты — ноды, не написав и строчки кода!

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

Все эти вещи экономят сотни часов программистов и именно поэтому Drupal используется на сайте Белого Дома США, Нью-Йоркской биржи, журнала The Economist и т.д. Drupal как никакая другая система имеет огромные возможности для оптимизации бизнес процессов в разработке, сокращая лаг между прототипом на бумаге и прототипом в коде.

Разработчикам же остаётся использовать по максимуму все преимущества Drupal, при этом помня о его недостатках, искать баланс между использованием готового кода и написанием своего. Я бы сформулировал это так — используйте готовый код (contrib модули) в количестве достаточном для реализации фундаментальных задач. Более мелкий функционал, требующий нестандартной для Друпала логики, должен быть под полным контролем девелопера. Иногда нужную функцию или класс можно просто скопировать с contrib модуля в свою логику, избавив приложение от потерь в производительности и стабильности, и сохранив себе нервы в будущем.

А что же бизнес?

Не буду платить за модули

Очень важно уяснить разницу между ускорением прототипирования, «набрасыванием» заготовки, и ускорением и удешевлением самой разработки. Очень часто клиенты (стейкхолдеры) выбирают Drupal только из-за убеждённости в его дешевизне, и не получив ожидаемых результатов за свои бюджеты, разочаровываются. Да, можно сделать вполне себе рабочий сайт с новостями, блогом и фотогалереей за полдня работы, его действительная стоимость — 200-300 долларов в зависимости от жадности разработчика. Но это будет стандартная замыленая тема оформления, ни одной примечательной детали в интерфейсе, набивший оскомину т.н. «Drupal look» и полностью дефолтная бизнес-логика.

Лет пять назад такие сайты-визитки вполне могли быть бизнес-моделью небольшой компании, но сейчас, когда все кто хотел уже имеют свои страницы в сети, начиная от простейших Wordpress и Joomla поделок и заканчивая enterprise проектами за сотни тысяч, с таким портфолио компания не имеет никаких шансов на рынке, разве что выстроив идеальную систему продаж.

В Европе и США бизнес начинает уяснять, что Drupal разработка — это не дёшевый процесс, и увеличение количества проектов с бюджетами за 100к тому хорошее доказательство. Даже если сайт довольно простой, сделать его правильно, с учётом стандартов и используя все преимущества Drupal, которые в перспективе сэкономят большие деньги, далеко не просто и не дёшево.

Как не парадоксально это звучит, но насколько легко можно «накликать» многие вещи, ровно настолько же сложно что-то писать под Drupal. Но оно того стоит.

Итого

Для тех, кто не осилил много текста.

  • Существует глобальная проблема — большинство Drupal сайтов переполнены огромным количеством неиспользуемого и глючного кода, что ведёт к снижению качества проектов в целом и ухудшает репутацию системы, не говоря уже о снижении мотивации девелоперов развиваться.
  • Проблему можно решить, научившись находить золотую середину между использованием готового кода и своего. Не использовать готовые модули в случаях, когда они решают лишь небольшую задачу. Свой же код должен быть полностью стандартным и совместимым с Drupal API. Так мы ограждаем себя от перехода на «темную сторону Drupal».
  • Бизнес должен понимать особенности правильной разработки под Drupal, чтобы избежать ненужных конфликтов и разочарований, и правильно расставлять приоритеты. Нельзя делать сайты на Drupal только потому, что это модно, что так сделал конкурент и т.д. Есть отличные альтернативы.
  • Drupal приложения обычно стоят дороже чем построенные на других open source системах, и на это есть объективные причины.
  • Главная особенность Drupal разработки — дешёвый функционал, дорогие детали. Если базовые вещи можно быстро и эффективно «собрать», то специфические запросы решаются сложнее чем у альтернативных систем или чистом языке, но только потому, что мы должны следовать стандартам работы с API, что в свою очередь даёт большие преимущества.
  • Компаниям, занимающимся Drupal, стоит уделять больше внимания технической подготовки специалистов, так как из десятка способов сделать что-то в Drupal, есть всего один или два по-настоящему правильных.

Значит ли всё выше написанное, что стоит смотреть в сторону других систем? Конечно нет!

Вопросы, возражения и негодования принимаются в комментариях.

Инспирэйшн, статистика и цитаты