Перед разработкой Drupal проекта, особенно большого, важно определиться со стандартами, которые будут использоваться на проекте. Таким образом все участвующие в проекте будут понимать каким правилам следовать во время разработки и поддержки проекта.
Это нужно чтобы:
- Облегчить поддержку проекта, т.к. в нем будет легче разобраться.
- Облегчить вход для новых разработчиков - они будут понимать что и как нужно делать благодаря описанным требованиям
- Уменьшить риски возникновения проблем совместимости.
- Избежать проблем в коммуницировании между членами команды.
Договариваемся о нумерации релизов проекта.
Работа над проектом, обычно, происходит итерациями. Используется система релизов, каждый из которых включает в себя определенный функционал. Для начала нам нужно навести порядок в наименовании релизов.
Вы можете внедрить любые правила, какие вам хочется, но, вы можете использовать стандарт Semantic Versioning. Этот стандарт был придуман одним из создателей GitHub и используется на многих проектах. Ппрофессиональные разработчики знакомы с этим стандартом поэтому вам будет легко внедрять его на своих проектах.
Drupal использовал свое собственное соглашение о именовании релизов модулей вида 7.x-*, 8.x-*. Но с выходом Drupal 8 и постепенной миграции на Drupal 9 сообщество решило перейти на Semantic Versioning (более подробно об этом).
Стандарты кодирования Drupal
Думаю, что большинство Drupal разработчиков слышало о стандартах кодирования Drupal. Эти стандарты описывают форматирование кода, наименование и расположение файлов, архитектурные паттерны. Для Drupal проектов эти стандарты являются обязательными, особенно если вы разрабатываете модули для сообщества.
Здесь я хотел бы отметить, что стандарты кодирования Drupal не распространяются на composer.json файлы где используются отступы в 4 пробела вместо обычных для Drupal 2х,
Для проверки стандартов кодирования обычно используют библиотеку PHP CodeSniffer с установленными правилами для Drupal. Инструкцию по установке можно найти здесь. Многие Drupal boilerplate проекты уже имеют эту библиотеку установленной.
Вы можете использовать continuous integration систему для проверки вашего кода используя PHP CodeSniffer.
Также можно внедрить проверку кода при срабатывании git хуков используя GrumPHP. Эта библиотека не позволит добавить в репозиторий невалидный код.
PHP стандарты
При разработке Drupal проектов вы также используете сторонние PHP библиотеки (например, описанные выше PHP CodeSniffer или GrumPHP). При проектировании и создании PHP библиотек рекомендуется использовать “PHP Standard Recommendations (PSR)”. Эти рекомендации позволят вам легко внедрить стороннюю библиотеку в ваш проект или разработать библиотеку, которую можно будет переиспользовать. Например, внедрение стандарта PSR-4 позволило сделать composer и облегчило создание и установку PHP пакетов.
CSS стандарты
CSS в Drupal проекте должно удовлетворять стандартам кодирования Drupal.
Как указано в документации Drupal использует архитектурный паттерн “Scalable and Modular Architecture for CSS (SMACSS)” для организации CSS. К сожалению, он не всегда удобен и при построении тем все большее распространения получает методология BEM (Block, Element, Modifier). BEM использует идею создания темы на основе компонентов и отлично подходит для создания библиотеки компонентов, которые могут быть использованы в вашей теме. Если вы не используете компоненты, то можно использовать методологию BEM просто для определения классов для элементов страниц.
Javascript стандарты
Для Javascript также определены стандарты Drupal. Но кроме этого нужно определить какую версию Javascript использовать на проекте.
Ядро Drupal использует Javascript стандарта ES6 (EcmaScript 2015). В папке core/misc вы найдете файлы *.es6.js и *.js. Предполагается, что разработчики работают с файлами *.es6.js, а *.js файлы, которые загружаются браузером, генерируются Javascript компилятором Babel для совместимости с браузерами, которые не поддерживают ES6 стандарт.
Какую версию Javascript использовать на проекте решать вам, но чем раньше вы это сделаете тем лучше. Можете использовать стандарт ES5 знакомый по Drupal 6 и 7, или ES6 + Babel если вам нужно поддерживать старые браузеры. Если вам не нужно их поддерживать то можете использовать просто ES6 в своей теме. Он поддерживается всеми браузерами вышедшими после 2013 года. Или же можете взять ES7 или ES8 + Babel если знаете, что проект будет поддерживаться долго и хотите использовать все нововведения Javascript.
Можно ли стандартизировать качество кода?
Насколько я знаю нет отраслевых стандартов которые бы задавали качество кода. Но мы можем сами оценивать качество по определенным параметрам, например:
- Покрытие тестами.
- Наличие дубликатов кода.
- Наличие комментариев.
- Сложность кода.
Данные параметры могут быть проверены используя PHP MessDetector или SonarQube для которых вы можете определить собственные правила. Дубликаты кода могут быть найдены с помощью библиотеки PHP Copy/Paste Detector.
При проведении ревью кода можно руководствоваться принципами SOLID:
- Single-responsibility principle - класс должен быть ответственен лишь за что-то одно
- Open–closed principle - программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации.
- Liskov substitution principle - необходимо, чтобы подклассы могли бы служить заменой для своих суперклассов.
- Interface segregation principle - узкоспециализированные интерфейсы, предназначенные для конкретного клиента лучше чем один многофункциональный интерфейс.
- Dependency inversion principle - объектом зависимости должна быть абстракция, а не что-то конкретное.
Данными принципами должны руководствоваться все программисты при разработке кода, но не всегда это происходит. Введение этих принципов в качестве стандарта прохождения ревью кода позволит определить четкие правила по которым код будет считаться качественным и сможет пройти проверку.
Стандартное окружение для всех разработчиков
На проектах часто возникают проблемы связанные с использованием разного окружения на локальных компьютерах разработчиков. Например, разные версии программного обеспечения могут вести себя по-разному или какие-то функции могут не работать на локальной машине и требуется время на установку и настройку специального ПО. Чтобы этого избежать, используйте стандартное окружение для всех разработчиков. Вы можете использовать Docker контейнеры или виртуальные машины и Vagrant для настройки единого окружения. Также вы можете взять готовые настройки окружения такие, как DrupalVM, Lando, Docksal.
Итог
Как вы видите существуют множество различных стандартов, которые вы можете использовать в Drupal проектах. Можно также упомянуть стандарты наименования патчей и веток в репозитарии, сообщений комитов. Вы сами решаете что вам нужно, а что нет. История программирования показывает, что введение стандартов помогает работать над проектами, особенно если над проектом работает несколько человек. Только хочу отметить что стоит подходить к этому вопросу обдуманно чтобы стандарты вам помогали, а не мешали в работе.