Написание лучшего кода WordPress: PHPStan
В самом последнем посте из этой серии (который, по общему признанию, был сделан некоторое время назад) я подробно рассказал о Composer и его файле блокировки.
Я рекомендую прочитать предыдущие две статьи, потому что Composer в конечном итоге сыграет свою роль в этом материале, которым мы будем делиться в этой и будущих статьях. Но если вы предпочитаете не догонять их (или уже знакомы с Composer), то суть предыдущих постов, соответственно, такова:
Я не рекомендую проверять каталог поставщика в вашем репозитории. Позже это может превратиться в огромный каталог и подорвать всю цель Composer.
Цель состоит в том, чтобы убедиться, что все используют одну и ту же версию зависимостей проекта — не старые версии, не новые версии — а одну и ту же версию.
При этом существует множество зависимостей или пакетов, которые мы можем установить, чтобы убедиться, что мы пишем код максимально возможного качества.
Конечно, некоторые из них могут быть в форме чего-то вроде стандартов кодирования, но на самом деле это больше правила, чем элементы написания высококачественного кода (хотя я не думаю, что их следует оставлять за рамками обсуждения — просто опускать). в это время 🙃).
Вернемся к рассматриваемым инструментам: какие инструменты помогают писать высококачественный код WordPress? Я собираюсь поделиться некоторыми из моих любимых, и я собираюсь рассказать о том, как мы можем запустить их все в кодовой базе.
Во-первых, давайте взглянем на статический анализ с помощью PHPStan.
Лучший код WordPress с PHPStan
Что такое статический анализ?
Сначала несколько слов о статическом анализе. А именно, что это? Это глоток, во-первых:
Статический анализ кода (также известный как анализ исходного кода) обычно выполняется как часть проверки кода (также известной как тестирование белого ящика) и выполняется на этапе реализации жизненного цикла разработки безопасности (SDL).
Статический анализ кода обычно относится к запуску инструментов статического анализа кода, которые пытаются выявить возможные уязвимости в «статическом» (не работающем) исходном коде с помощью таких методов, как анализ уязвимостей и анализ потока данных.
Подумайте об этом так: это способ проанализировать программу на наличие потенциальных ошибок, которые вы можете не заметить при работе с кодовой базой.
То есть есть проблемы, баги, проблемы с безопасностью, которые могут присутствовать, но вы не можете их обнаружить по ряду причин (наименьшая из которых заключается в том, что вы находитесь слишком близко к коду).
Однако со временем сообщество разработчиков научилось анализировать код, генерировать наборы правил и создавать инструменты, помогающие найти все вышеперечисленное.
Статический анализ WordPress-ориентированного кода
И здесь в игру вступает PHPStan.
Как уже упоминалось, целью пакета является выявление ошибок или ошибок, существующих в вашем коде, до того, как ваш код будет использован кем-то, кроме разработчиков, выделение их и предоставление вам возможности их исправить.
Поскольку подобные инструменты исследуют кодовую базу (а не запуск кода), не всегда возможно получить четкую картину. Это означает, что мы можем получить ложные срабатывания.
Подробнее об этом чуть позже.
Если вы заинтересованы в том, чтобы начать работу с PHPStan для вашего кода, это легко. После установки просто не забудьте настроить его так, чтобы он не смотрел в vendorкаталог или, скажем, в ядро WordPress.
Вместо этого попросите его изучить ваш код.
Установка PHPStan
Во- первых, в вашем composer.jsonфайле добавьте следующую строку в require-devраздел:
"phpstan/phpstan": "^0.11.12"
Затем запустите composer updateв своем терминале.
После установки вы можете запустить его для отдельного файла, каталога или набора каталогов. Если вы читали мои предыдущие сообщения об организации кода, то знаете, что я сторонник сохранения большей части исходного кода проекта src, чтобы вы могли запустить что-то вроде этого:
$ vendor/bin/phpstan analyse src
Это будет генерировать выходные данные на основе того, что найдет утилита.
Помните ранее, когда я сказал, что он может найти такие вещи, как ложные срабатывания? Вот более подробное описание того, что вы можете увидеть:
- В функции передаются дополнительные аргументы (например, функция требует два аргумента, код передает три)
- Дополнительные аргументы, передаваемые функциям print/sprintf (например, строка формата содержит один заполнитель, код передает два значения для замены)
- Очевидные ошибки в мертвом коде
- Магическое поведение, которое необходимо определить.
Все вышеперечисленное прямо из репозитория.
Именно здесь уровни правил могут иметь решающее значение, хотя может потребоваться небольшая настройка, чтобы получить уровень, подходящий для вашей команды или вашего проекта.
Как насчет анализа для WordPress?
Виктор Сепе поделился со мной этим ресурсом (на самом деле он его автор), и я думаю, что это что-то актуальное и полезное. Идея упаковки проста:
Это решает все проблемы, которые у меня возникали при анализе кода для WordPress.
Неплохо, правда?
Проанализируйте свой код
Независимо от вашего проекта, организации вашего кода или уровня, на котором вы запускаете эту конкретную утилиту, цель всегда состоит в том, чтобы повысить уровень качества кода, который мы пишем для WordPress.
Установка его как пакета Composer, а затем запуск его в вашем srcкаталоге — это шаг в правильном направлении.
Как было сказано ранее, я собираюсь поделиться несколькими другими инструментами, а затем рассказать, как запустить их все в кодовой базе до фиксации кода в репозиторий.
Примечание
Если у вас возникла проблема с установкой пакета, Дэйв Макки связался со мной и предложил аналогичную проблему и ее решение.