ShvetsGroup

На DrupalCamp Kyiv 2011 я рассказывал о наших разработчиках, которые публикуют свои модули на drupal.org.

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

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

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

Contrib-модулями называются модули, которые были созданы и опубликованы на drupal.org сторонними разработчиками. Любой желающий может их использовать (contribution).

Contrib-модули и вклад в развитие Drupal

Эти contrib-модули являются вкладом drupal-разработчиков по всему миру в развитие Drupal.

Есть и другие способы, как можно сказать спасибо тем, кто развивал Drupal до вас, кто создавал полезные модули, писал документацию, тратил свое время на тестирование чужих модулей и исправление ошибок, а также ребятам из команды безопасности (Security Team), которые внимательно изучали код в поисках уязвимостей и принимали меры по их устранению.

Это может быть:

• Членство в Drupal Association. О том, что это дает и на что тратятся членские взносы лучше почитать на сайте Drupal Association.
• Написание документации.
• Перевод документации на родной язык.
• Перевод строк ядра и модулей на родной язык. Детали на сервере локализации.
• Участие в организации Drupal-мероприятий в своей стране.
• Участие в зарубежных Drupal-мероприятиях.
• Создание модулей для Drupal.
• Создание и проведение тренингов.
• Запись обучающих скринкастов про Drupal.
• Популяризация Drupal (без спама, холиваров и троллинга).
• Создание сайтов на базе Drupal. (Да, это тоже вклад в развитие Drupal!)
• Направление части прибыли от проекта на развитие Drupal. Это может быть как локальное использование, так и перечисление в виде пожертвования Drupal-разработчикам.
• Участие в качестве спонсоров на Drupal-мероприятиях.

Но самое доступное и простое - как мне кажется - это сделать патч и опубликовать его на drupal.org!

Это не так сложно, как публиковать модуль и дешевле, чем оплачивать членство в Ассоциации Drupal. Патч можно опубликовать достаточно быстро. Ваша активность поможет вам быстрее получить право на публикацию модулей, а также создаст вам репутация серьезного человека, который в Drupal-сообществе «всерьёз и надолго».

Но сначала нужно рассмотреть несколько ключевых моментов:

• Можно ли использовать contrib-модули для серьёзных проектов?
• Стоит ли тратить время на создание и публикацию патча на drupal.org?

Почему мы используем модули с Drupal.org?

У нас в компании мы активно используем contrib-модули с drupal.org. Почему мы используем модули, качество некоторых модулей оставляет желать лучшего, а не создаем новые для своих проектов?

Потому что они уже написаны! Нам не нужно тратить время на их повторное написание (Development) и последующую поддержку кода (Support). По нашему опыту, соотношение выглядит примерно так:

Support = 3 × Development

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

Если мы публикуем модуль, который мы создали, на drupal.org, то можем уменьшить время на поддержку кода на 30%, то есть формула будет выглядеть так:

Support = 2 × Development

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

Подводные камни при написании кастомного кода

Плюсы использования contrib-модулей мы уже рассмотрели, а теперь минусы написания своего кастомного кода:

• Не решает проблему интеграции компонентов при последующем использовании вашего кода. Проблема интеграции решается путем детального аудита модуля перед его использованием (осторожность), а также ведением базы знаний проекта и моделей в общем (опыт).
• Вряд ли будет содержать меньше ошибок, чем среднестатистический contrib-модуль с drupal.org.
• Требуется время на тестирование и исправление ошибок.
• Клиент получает код привязанный к разработчику (Vendor Lock-in), что не хорошо.

Писать свой код или использовать чужой?

При принятии решения при выборе модуля или написании своего кода нужно учесть, что кроме самого кода в contrib-модуле важна поддержка сообществом этого модуля и она может выражаться в четырех действиях:

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

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

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

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

Кроме того, многое может рассказать активность в issues модуля.

Если разработчик модуля не появлялся в issues уже давно, то, вероятно, он забросил проект. Если вы находите модуль интересным и полезным, а код таковым, который стоит использовать и развивать, то вам нужно стать со-разработчиком (co-maintainer) этого модуля. Для этого нужно заявить о том, что модуль заброшен и через 2 недели вы сможете стать его активным разработчиком. Подробности о том, как это сделать на странице Dealing with abandoned projects.

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

Кроме того, можно проверить соответствие кода модуля стандартам кодирования, которые приняты в Drupal-сообществе.

Это можно сделать визуально(скачать модуль и посмотреть код), либо использовать модуль Coder. Оба варианта позволят сделать быструю оценку качества кода.

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

Мы можем также оценить удобство использования (usability) модуля. Для этого его нужно установить и посмотреть что именно он нам будет показывать.

Да! Чуть не забыл! У любого модуля есть такой критерий качества как автор (разработчик). Откройте профиль и посмотрите чем он вообще занимается, насколько активен, какой у него сайт. В этом случае «сапожник без сапог» не катит - если у человека нет активности на drupal.org, то очень вероятно модули не будут сделаны на высшем уровне.

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

На этом можно остановиться. Я думаю, что анализ этих критериев даст представление о качестве модуля, который вы собираетесь использовать. Следующим шагом является Code Review или анализ кода модуля, но чтобы это делать нужны глубокие знания архитектуры Drupal, стандартов кодирования и время.

Исправление ошибок в contrib-модулях

— Почему мы должны тратить время на исправление багов в contrib модулях?
— Чтобы не натыкаться на них самим в будущем и помочь другим с той же задачей.

Исправляя ошибку, мы:

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

Сколько времени занимает исправление багов в contrib модулях?

Исправление ошибок требует времени, которое стоит денег.

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

Если время разработки модуля с нуля принять за 100%, то время на исправление этой обнаруженной половины ошибок составляет +50% (а в некоторых случаях и все +100%).

Для завершения работы над фичей не всегда требуется исправление абсолютно всех ошибок в модуле, поэтому время в среднем варьируется в пределах +10%-40%.

Зачем мне делать патч и публиковать его в issues модуля, если можно быстро «похачить» код модуля и решить проблему?

Потому что это не выгодно!

• Этот же модуль, возможно, будет использован в другом проекте и снова нужно будет «хакать» его.
• Информацию о «хаках», (не патчах) нужно где-то сохранять. Патчи можно хранить в системе контроля версий, но хак - это изменение в коде модуля.
• Возникают проблемы при обновлении версии модуля, так как нужно опять вносить изменения в код вручную.
• Патч сделать очень просто и выигрыш от его использования довольно большой. Его проще хранить в системе контроля версий и его можно накатывать и откатывать быстро и делать это много раз.
• Публикуя патч, мы помогаем развитию модуля. Другие люди тоже будут сталкиваться с этой проблемой и им будет приятно, что кто-то уже сделал патч, который они могут использовать. Через какое-то время они тоже захотят опубликовать свои патчи, так как сами видят пользу от этого.
• Публикуя патч мы поощряем и ободряем разработчика, который не знает кто пользуется его модулем и представляет ли этот модуль ценность для других людей. В этом случае возможна дополнительная мотивация разработчика для дальнейшего развития модуля.

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

После этого сделать быстрое изменение в коде или уведомить клиента/пользователей об известных проблемах. В изменённом коде стоит оставить в комментариях подробное описание проблемы, как она была решена и что ещё нужно сделать (используйте тег @TODO).

Компания заинтересована в том, чтобы, как только проект будет сдан или выполнен релиз, был создан патч, опубликован в issues на drupal.org, а файл патча был добавлен в SVN в соответствии с теми правилами, которые используются для работы с патчами в нашей компании.

Почему качество кода некоторых contrib-модулей так низко?

Качество не низко, а случайно. Contrib-модули пишут разные люди, которые могут быть как профессионалами, как мы, так и дилетантами, которые не соблюдают стандарты кодирования, не используют API Drupal и не стремятся писать оптимальный и безопасный код.

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

Если качество contrib модуля очень низко и он кишит багами, что делать?

Когда качество contrib модуля намного ниже общепринятых стандартов, целесообразно полное переписывание модуля, если двукратное расчетное время переписывания (200% времени разработки с нуля) может быть покрыто бюджетом фичи вашего проекта. При этом компания берет на себя последующий риск трат времени на поддержку модуля (оставшиеся 100%).

Зачем компании заботиться о качестве кода contrib-модулей?

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

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

Улучшения и новые фичи в contrib-модулях

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

• Сначала выявляется недостаток.
• Потом приходят мысли о том, как этот недостаток исправить.
• Затем, при наличии возможности и ресурсов, кто-то воплощает в жизнь и решает проблему.

Если все время только и повторять то, как все плохо, ждать от кого-то решения, искать виноватых, бояться что «все летит в пропасть» — ничего не изменится, всё так и останется на первом шаге.

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

Инициатива, решительность и последовательность уже приведет конкретную идею к воплощению.