Пролог

Рано или поздно веб-программист уходит с проекта и на его место приходит другой веб-программист. “Как сделать так, чтобы смена веб-программиста проходила безболезненно для заказчика сайта” – эта проблема волновала меня долгие годы.
Расскажу о 7 ступенях, по которым мне пришлось поднятся, прежде чем получил ответ на свой вопрос.

1–ая ступенька, стиль программирования
В бытность свою веб-программистом писал крутые, как казалось, программы в рекурсивном стиле:

// Вычисление факториала N! = 1 * 2 * ... * N
// Факториал не натурального числа примем равным нулю
function factorial ($N) {
if (1 > $N) return 0;
if (1 == $N) return 1;
return (factorial($N - 1) * $N);
}
?>

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

// Вычисление факториала N! = 1 * 2 * ... * N
// Факториал не натурального числа примем равным нулю
function factorial ($N) {
if ((intval($N) != $N ) || (1 > $N)) return 0;
$Fac = 1;
for ($i = 1; $i <= $N; $i ++) {
$Fac *= $i;
}
return $Fac;
}
?>

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

• SMTP-класс
• класс-прослойка между PHP и MySQL
• класс обработки ошибок
• класс корзина для E-Commerce
• …

Брал готовые классы, правил их как мне надо и использовал на сайтах. Работа сразу пошла вперед, благо основная часть кода была написана автором класса.
Прошло время и опять столкнулся с тем, что правленый мной класс другие не могли поддерживать. Другому программисту проще взять класс-исходник и править его или применить свой любимый класс.
Пришлось отказаться и от классов.
Для краткости пропущу изложение идей PHP-unit, рефракторинга, Selenium и других интересных технологий программирования. Они работали и делали свое дело. Но если под какую-то технологию трудно найти программиста на его поддержку и сопровождение, то использование такой технологии в будущем будет вызывать проблемы у заказчика.
Тем более что к тому времени стало набирать силу гораздо более интересное явление – готовые “движки” под ключ.
3–ья ступенька, движки
Собирал их по всем Интернету, раскладывал по гигабайтным папочкам, запускал на локальном сервере, любовно сравнивал их характеристики и отбирал самые удачные в своей нише.
Движки это красота. Все готовое, нужно было только ставить и наслаждаться. Если движок что-то делал не так, то небольшой правкой кода (на жаргоне “хак”) можно было привести движок к нужному мне функционалу. Разве можно было сравнивать такие возможности с каменным бинарным exe-шником.
Прошло время и опять столкнулся с тем, что сайт с движками тоже тяжело поддерживать:

• Движки постоянно дрались между собой за общие ресурсы. За папку “/forum”, за папку “/image”, за файл “/index.php”, за место в дизайне на главной странице,…
• Приходилось разводить движки по разным доменам третьего уровня. Это порождало новые проблемы: с куками, с запоминанием лишней точки в домене, с обновлением по FTP,…
• На каждом движке была своя система логинов-паролей, своя система профилей и свой стиль набивки материалов, что очень раздражало посетителей
• Каждый движок имел свой суверенный поиск
• Движки время от времени обновлялись и помимо обновления масса времени уходила на поддержание в рабочем состоянии любимых хаков.
• …

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

Если б я был султан,
Я б имел трёх жён
И тройной красотой Был бы окружён.
Но с другой стороны
При таких делах
Столько бед и забот.
Ах, спаси Аллах!

Не сильно радовала перспектива провести всю свою жизнь между взаимными движковыми обидами и постоянным обновлением версий движков и хаков. Также было совершенно непонятно, кто будет поддерживать “зоопарк” движков на сайтах после моего ухода с проектов.
4–ая ступенька, системы управления сайтом (CMS)
Выход пришел в виде систем управления сайтом.
Любой специализированный движок с легкостью перекрывает аналогичные возможности CMS. Но зато у CMS возможности разных движков встроены в ядро и хорошо ладят между собой. Единая регистрация, единое управление любыми возможностями, единый дизайн в котором одновременно могут выдавать свои результаты разные отделы CMS, единый поиск. Вот далеко не полный перечень того единого, что прекрасно существует в рамках одной CMS.
Если CMS проигрывает каждому движку по части специализации, то по легкости сопровождения CMS даст 100 очков вперед любой связке из 5–6 движков.
Поддерживать CMS просто, потому что это один движок. И когда у клиента появится необходимость сменить веб-мастера, ему не нужно будет искать специалиста по связке из движков. Достаточно будет найти специалиста по выбранной CMS.
В качестве CMS был выбран Drupal.
Легкая установка, легкое сопровождение. Сайты на Друпале у меня стали плодится как кролики. Освободившееся время тратил на то, что лез в ядро и правил его под нужды проекта.
Но если разнокалиберные движки на одном сайте обновлялись по очереди, то версию Друпала на всех сайтах нужно было обновлять одновременно. Также одновременно приходилось обновлять все хаки. Вначале еще это было терпимо, но по мере роста количества поддерживаемых сайтов, возня с хаками ядра стала сильно раздражать.
5–ая ступенька, использование API
“API, вот решение вопроса с хаками”, родилась мысль. Благо в Друпале API на редкость элегантное и приятное в использовании. Не лезть в ядро, а все необходимое получать через API. Это так естественно.
Но в один прекрасный день Друпал поменял свое API. И пришло осознание, что использование API влечет такие проблемы, как и хак ядра Друпала. Вся разница лишь в том, что API меняется пореже, чем происходит обновление версий в Друпале с ликвидацией критических ошибок.
Но все равно, после моего ухода с проекта рано или поздно API сменится в очередной раз. И клиент окажется брошенным на камни с моим API-шным кодом. Ему придется искать специалиста, знающего API и который сможет переписать код на новое API. Это будет стоить клиенту гораздо дороже, чем наем обычного специалиста по Друпалу.
6–ая ступенька, самописные модули
Помимо ядра и API, в Друпале существует прекрасная возможность написания своих модулей. При мелких обновлениях Друпала самописные модули не требуют никакого обновления.
Веб-программисту, сменившему меня, виделось мне, будет гораздо легче разбираться с текстом моих модулей, чем отлавливать по всему движку API-шные вставки. Самописные модули в друпаловском стандарте были бы прекрасной возможностью получить доступ к низкоуровневым возможностям Друпала и в то же время облегчить свою последующую поддержку.
Но оставался нерешенным тот же самый вопрос. Имею ли я право навечно обременять клиента поисками специалистов, которые регулярно будут переписывать все мои самописные модули?
7–ая ступенька, сторонние модули
После долгих раздумий заставил себя смотреть только в сторону готовых сторонних модулей, написанных другими друпальщиками. Их в Друпале написано около двух тысяч на все вкусы. Установка стороннего модуля занимает всего несколько минут.
При мелких обновлениях Друпала сторонние модули вообще не требуют замены. У сторонних модулей есть хозяева, которые обновят модули при смене API или версий. Казалось, надо будет лишь подождать пока произойдет обновление установленных на сайте сторонних модулей и можно будет обновить сам Друпал.
Но когда Друпал в течение нескольких месяцев поменял сначала API, а потом обновился с 4–ой версии на 5–ую, то у меня закрались некоторые сомнения в верности моих мыслей. Прошло несколько месяцев после перехода на 5–ую версию, а до сих пор половина модулей из версии 4.* так и не обновились до версии 5.*. И похоже, не обновятся уже никогда.
Стало понятно, что надежность сильно зависит от количества сторонних людей, готовых обновлять код.

• Самая низкая надежность у кода, написанного одиноким программистом с помощью API. Поддержка кода полностью зависит от автора-программиста.
• Код, выложенный на Drupal.org в виде модуля, доступен для многих и привлекает внимание многих программистов. Поэтому предположительно он более надежен. Если идея модуля удачна, то он обновится быстро или автором модуля или теми, кто пользуется этим модулем. Но в каждый второй модуль не переживает смену API или сильную смену версий Друпала.
• Код ядра Друпала и его встроенных модулей самый надежный в смысле поддержки. За ним стоят тысячи друпальщиков, присылающих свои обновления для ядра Друпала и его стандартных модулей.

За одиноким программистом стоит только он сам. За Друпалом стоят тысячи. Сколько же людей стоят за каждым сторонним друпальским модулем? Этого, к сожалению, на модулях не пишут и выяснится только после смены API или сильной смены версии Друпала. Выбор плохо поддерживаемого модуля может в будущем повлечь невозможность обновлять проект.
Как выиграть в рулетку с модулями? Пришлось мысленно разделить сторонние модули на 3 группы:

• “Зеленые” модули. При отключении таких модулей на сайте сохраняется полный доступ к накопленной информации;
• “Желтые” модули. Их отключение повлечет потерю доступа к части накопленной информации. Но путем работы с базой можно попробовать вручную конвертировать недоступную информацию к какому-нибудь стандартному виду;
• “Красные модули”. При отключении такого модуля вернуть к использованию наработанные этими модулями данные практически невозможно.

Примеры зеленых модулей:

• Все модули в стандартной поставе Друпала
• редактор TinyMCE
• Read More Tweak
• Blog Information
• captha
• comment_mover
• темы
• Blog Information
• Print Friendly Pages
• Login Toboggan
• Comment Mail
• Blogger - топ всех блогов
• Remember me
• вики-модуль wikitools

Примеры желтых модулей

• Signature module
• Quote
• вставка тэгов phpBB
• Web Links

Примеры красных модулей

• webform
• Content Construction Kit
• e-commerce
• Gallery2
• fudforum
• вики-модуль Liquid

Стал реализовывать функционал сайтов только через зеленые модули.
Ставить желтый или красный модуль означало возможность жестоко подставить клиента при ближайшей смене API или сильной смене версий Друпала, которая произойдет в мое отсутствие. Такие модули использовал только при крайней необходимости, сто раз продумав этот шаг. При выборе желтого или красного модуля всегда старался брать не самый подходящий под требования проекта, а самый часто цитируемый и поддерживаемый, пусть он даже реализовывал только часть нужного мне функционала.
В результате смена API и сильная смена версий Друпала проходит теперь на моих сайтах очень просто. Нужно подождать 2–3 месяца, сменить Друпал и поменять все сторонние модули которые успели обновится к этому сроку под новое API или новую версию Друпала. Даже если какие-то зеленые модули так и не обновились, то сайт прекрасно будет существовать без них.
Желтых и красных модулей у меня в установке обычно нет или в единичных количествах. Выбираю их среди самых поддерживаемых модулей, поэтому в течение 2–х месяцев они обычно уже обновляются.
Райская установка CMS
Пройдя 7 ступеней, попал в настоящий рай:

Спешу рассказать, что в раю принята такая установка динамических сайтов:

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

Поддержка сайтов в раю до смешного легкая. Сайты сохраняют свой функционал даже при смене API и сильной смене версий Друпала. Обновление версий на друпаловских сайтах занимает полчаса на сайт и отлажена как часы. И что приятно, смену версий может провести даже самый начинающий житель рая.
Грустная новость. В раю очень мало веб-программистов и веб-дизайнеров. Раньше они собирали жатву практически с каждого сайта, теперь одного веб-программиста и одного веб-дизайнера хватает для обслуживания десятков сайтов, да и то часто их помощь самая минимальная. На постоянной основе работает лишь специалист по чистому использованию CMS.
Язык сверхвысокого уровня, язык CMS
Райская установка CMS без единой строки программирования это следующее поколение языков веб-программирования, язык сверхвысокого уровня. Его еще можно назвать языком CMS. У каждой CMS он свой.
Роль стандартных конструкций обычного языка программирования в CMS выполняют модули. Обращение к стандартным функциям языка и подстановка нужных параметров в языке CMS тоже существует и выглядит как щелканье галочками в настройках модуля.
На вход языка CMS подается активность посетителей, на выходе получаются готовый сайт. Умелым написанием программы CMS (т.е. настройкой CMS) разработчик создает сайт, который превращает активность посетителей в готовый сайт.
Практически, выбирая CMS, программист выбирает язык программирования сверх-высокого уровня, которым будет творить последующие годы.
Самодостаточность языка CMS
Язык CMS это полноценный язык. Он практически не нуждается в низкоуровневых самописных вставках. Большей частью такие вставки делаются по привычке веб-программиста программировать, а не от необходимости.
Если ограничить себя рамками языка CMS, то, к удивлению, оказалось возможным обеспечить большинство потребностей посетителей средствами самой CMS.
Проекты, сделанные на одном лишь языке CMS, просты в поддержке и надежны в работе. (Например, наш сайт Razgonka.ru принципиально сделан без единой строчки самописного кода).
Мастерство
Для привлечения к себе внимания веб-программистов, системы управления сайтами дают им ту или иную возможность встроить встроить в себя низкоуровневый самописный код. Но это не означает, что нужно использовать такую возможность.
Любой самописный байт потребует пожизненной поддержки, которая тяжким бременем ляжет на бюджет проекта. Самописные байты накапливаются и наступит момент, когда их поддержка съест весь бюджет выделенный на поддержку проекта. За этим последует крах проекта.
Легко определить уровень разработчика сайтов на CMS. Посмотрите, насколько он склонен в своих проектах применять код, за которым стоит только один человек. Неумеренное использование красных модулей тоже выдает специалиста, который не заботится о будущем проекта.
Профессионализм разработчика сайта на CMS заключается в том, чтобы последовательно развивать сайт и при этом опираться только на код, который поддерживают как минимум десятки человек, а еще лучше сотни и тысячи. Только при этих условиях динамический сайт будет годами устойчиво работать и развиваться, часто при весьма скромном бюджете.
Ссылки в тему
Программирование:

• Книга “Теория рекурсии для программистов”
• Он-лайн PHP-журанал PHPinside.ru
• Бесплатные PHP-классы, PHPClasses.org
• “Если б я был султан”: текст | караоке
• Гимн простоте, “Getting Real”

CMS Drupal:

• Официальные сайты: Drupal.org | Drupal.ru
• Гимн Друпала
• Модули Друпала: полный список, 1854 шт. | обновления
• Темы Друпала 5.x: полный список, 58 шт. | обновления
• Хуки Друпала
• Техника мелких PHP-вставок: снипиты для блоков
• Будущее, Lisp-подобный язык Dript заменит PHP в нодах

Постоянный адрес статьи:

• Razgonka.ru/rai

Обсуждение похожей темы "Drupal и будущее веба" - http://www.drupal.ru/node/5323