«> Как определить, хорошо ли выполнен ваш проект Drupal 8? Автор: Адам Оквиека Разработчик полного стека Опубликован: 30-04-2019 Категория: Drupal

Перед тем, как принять готовый проект от подрядчика, обязательно проверьте, хорошо ли он выполнил свою работу. К сожалению, многие компании/фрилансеры не знакомы с Drupal, но принимают заказы на создание сайтов на базе этой CMS. Чаще всего тестирование сайта клиентом заключается только в проверке лицевой части и функциональности — если все работает и выглядит хорошо, значит, проект должен быть выполнен правильно … Однако таким образом мы не будем проверять, как сделан бэкэнд и какого качества код, подготовленный программистами. В этом тексте мы представляем способы проверки кода веб-сайта Drupal 8, которые устранят связанные с ним проблемы в будущем.

1 GIT-система контроля версий

С ее помощью мы полностью контролируем весь код проекта. Любые изменения, внесенные в код, будут записаны и доступны для просмотра. Весь процесс доставки кода должен быть основан на Git. Загрузка файлов из локальной среды на рабочий сервер должна выполняться с помощью команд Git в командной строке.

Чтобы проверить, выгружен ли проект в Git, в главном каталоге проекта должна быть папка .git и файл конфигурации. В конфигурации мы находим URL-адрес «удаленного источника», где доступен текущий код проекта.

2. Composer — справка по управлению пакетами

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

Если проект был создан с использованием Composer, структура каталогов в основной папке проекта должна быть разделена в поставщика и веб/docroot.

Все зависимости хранятся у поставщика, а Drupal установлен в web/docroot. Следующим шагом будет проверка файла composer.json. Раздел 'require' должен содержать все модули в каталоге web/modules/contrib. Если в каталоге web/libraries есть какие-либо библиотеки, они должны быть в разделе «репозитории».

3. Модули — ключ к успеху Drupal 8

Модули — очень важная особенность Drupal. Все они вместе с имеющимися расширениями находятся в каталоге web/modules. Каталог должен быть разделен на:

contrib — содержащий все написанные сообществом модули, доступные на drupal.org, custom — который включает специальные модули, написанные разработчиками, ответственными за проект. Каталог contrib

Во-первых, давайте посмотрим на каталог contrib. Если количество включенных в него модулей исчисляется десятками, а проект вообще не был обширным, это может означать, что разработчики пошли легким путем, создав сайт на Drupal CMS 8 и захотели сделать все с наименьшими затратами, устанавливали все, что хотели. Вам также следует проверить качество установленных модулей, потому что многие из тех, что доступны на drupal.org, находятся в версии для разработчиков или в бета-версии и не подходят для загрузки в производство в этой форме. Лучше всего, если модуль на drupal.org будет зеленого цвета — тогда мы можем быть уверены, что с ним все в порядке.

Custom

directoryКогда дело доходит до модулей в пользовательской папке, мы должны быть особенно осторожны. Здесь находится весь код, написанный программистами. Модули должны быть разделены на функциональные возможности, т.е. один модуль должен отвечать за одну конкретную функциональность, например, для информационного бюллетеня должен быть отдельный модуль, а для интеграции с системой должен быть отдельный модуль. Плохая практика — создавать один модуль с бессмысленным именем, например, 'common', и бросать туда все.

У каждого модуля должно быть имя, соответствующее тому, что он делает, то есть модуль для отправки информационного бюллетеня является называется «информационный бюллетень», а модуль для интеграции с elasticsearch называется «elastic», «elastic_integration» и т. д.

После входа в модуль мы должны сначала увидеть файл .module. Если в нем сотни или тысячи строк, это может быть ошибкой. Конечно, вы все еще можете писать такой код, но он структурирован и может перестать работать в будущих обновлениях (особенно с Drupal 8 до Drupal 9). Большинство функций должно находиться в каталоге src модуля.

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

Документирование кода также важно. После ввода любого файла с окончанием php над функциями должны быть аннотации, помещенные в/** * /. Здесь вы можете найти информацию о том, для чего используется данная функция/метод, какие аргументы она принимает и что возвращает.

4. Кожа — хороший графический дизайн

В каталоге web/themes мы найдем , как и в случае с модулями, 2 каталога — custom и contrib. В contrib есть готовые скины, загруженные с drupal.org, и пользовательские скины, созданные разработчиками.

Готовые скины не должны вызывать никаких проблем, если они реализованы правильно, но кастомные скины — это отдельная тема.

Пользовательский скин в файле .info.yml должен содержать информацию о том, создается ли скин с нуля разработчиком или наследуется от готового скина (например, начальной загрузки). В этом файле вы также найдете список всех регионов сайта. Если их много, и их названия имеют тип header1, header2, footer_bottom, footer_bottom_after ', значит, у разработчика не было лучшей идеи для реализации графического дизайна. Названия регионов должны быть четкими и точными, а их количество в большинстве случаев должно быть не более 10.

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

В скине должны быть каталоги css и js. Каталоги должны состоять из множества файлов, которые отвечают за различные элементы страницы, созданной в Drupal 8. Если есть только один файл style.css и один файл script.js, и оба имеют несколько тысяч строк, это не очень хорошо для программист./p> Резюме

Благодаря таким тестам мы можем проверить, пытались ли разработчики создать проект хорошего качества, или они хотели сделать его «так долго, пока он работал». Также стоит предъявить требования перед запуском проекта, чтобы Drupal 8 был установлен как композитор, модули, используемые на веб-сайте, не были в версии для разработчиков или бета-версии, а код был хорошо документирован и загружен в Git. Программисты часто хотят сэкономить время, чтобы изучить Drupal, делать то, что они находят в первом туториале.

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