Как скачать модуль с Drupal.org и не облажаться: Часть II

Аватар пользователя kalabro

Это продолжение статьи Как скачать модуль с Drupal.org и не облажаться: Часть I.

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

5. Issue queue [ишью кью] — встроенный баг-трекер на Drupal.org с поддержкой версий, статусов и поиска.

Как скачать модуль с Drupal.org и не облажаться

Количество открытых запросов в Issue queue модуля само по себе ничего не говорит.
Перед скачиванием нужно открыть и просмотреть список багов и убедиться, что они, во-первых, своевременно исправляются и не висят годами в трекере, и, во-вторых, что на данный момент нет открытых багов, которые совершенно точно помешают вам работать с модулем.
Если эти условия не выполняются, то см. Часть III «Я не уверен в модуле».

6. Документация

Если разработчик модуля что-то написал не на php, а на человеческом языке, то это обязательно к прочтению. Закон. Не шутите с законом.
Написать документацию к модулю — это настоящий подвиг, друзья! Я бы ссылку “Read documentation” для таких модулей сделала <h2> красным цветом. 80% ваших вопросов отпадёт, если вы пролистаете информацию на странице проекта, документацию и README.txt.

7. Демо

Демки обычно живут на поддоменах сайтов авторов. Я думаю, не за горами какой-нибудь стартап на эту тему.
Очень полезно бывает посмотреть на работающий модуль в том виде, в котором его предполагает использовать сам разработчик.
Если ссылки “Try out a demonstration” нет, можно запустить модуль на http://simplytest.me/, однако там его придётся устанавливать и настраивать самому.

8. Аналогичные и родственные проекты

В самом низу правого сайдбара иногда можно найти блок “Related projects”. Возможно, именно там вы найдёте недостающий пазл для вашего сайта.

Как скачать модуль с Drupal.org и не облажаться

9. Описание проекта

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

10. Ссылки для разработчиков

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

Ссылка “Repository viewer” позволяет просмотреть структуру и код проекта ещё до скачивания. Для некоторых разработчиков, которые код читают быстрее, чем английский текст, это экономит время. Я в том числе отношусь к этой категории людей и не скачиваю ничего нового, не заглянув в Repository viewer.

Как скачать модуль с Drupal.org и не облажаться

Там можно прочитать README.txt, INSTALL.txt и .info файл.

View change records — это нововведение, позволяющее каждому проекту на Drupal.org вести свой Changelog наподобие https://drupal.org/list-changes. Вероятно, ссылка должна помогать при переезде с 7‑ки на 8‑ку. Будет ли кто-то из разработчиков писать эти change records, я не знаю.

11. Release Notes

Зато я наверняка знаю, что авторы модулей заполняют полезной информацией обязательное поле Release Notes (11) при создании следующего релиза проекта на Drupal.org. Туда стоит заглядавать и при обновлении, и при первой установке модуля.

Как скачать модуль с Drupal.org и не облажаться

12. Тесты тяжело писать, тяжело поддерживать, тяжело запускать.

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

Что ж, мы рассмотрели основные критерии качества проекта на Drupal.org, по которым можно оценить модуль ещё до скачивания и установки на сайт.

В третьей части я расскажу, что делать, если модуль всё-таки нужен, но он выглядит недостаточно надёжно.

А пока можно почитать Часть I и подискутировать в комментариях.

Комментарии

Аватар пользователя Alex Malkov

По поводу версий (releases) и

По поводу версий (releases) и то, как они выделяются цветами.
Интуитивно понятно, что красный - это еще в разработке и недостаточно стабильный. Зеленый - можно ставить, все ок. А вот для чего желтый цвет? Что он обозначает?
Спасибо.

Аватар пользователя kalabro

Жёлтым выделяются официальные

Жёлтым выделяются официальные релизы всех веток, кроме рекомендуемой (она может быть только одна).
Например, у модуля Yandex.Metrics рекомендуемая ветка 1.x, поэтому официальный релиз 2.0-beta2 жёлтый. В данном случае релиз 2.0-beta2 довольно стабильный, поддерживаемый, и ветка активно развивается.

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

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