Написання кращого коду 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?
Viktor Szépe поділився зі мною цим ресурсом (насправді його автором), і я вважаю, що це щось актуальне та корисне. Ідея пакета проста:
Це вирішує всі проблеми, які у мене виникли під час аналізу коду для WordPress.
Непогано, правда?
Проаналізуйте свій код
Незалежно від вашого проекту, організації вашого коду чи рівня, на якому ви запускаєте цю конкретну утиліту, суть завжди полягає в тому, щоб покращити рівень якості написання коду WordPress.
Встановлення цього як пакета Composer, а потім його запуск у вашому srcкаталозі є кроком у правильному напрямку.
Як було сказано раніше, я збираюся поділитися кількома іншими інструментами, а потім розповім, як запустити їх усі з кодовою базою перед тим, як закріпити код у репозиторії.
Примітка
Якщо у вас виникла проблема під час спроби налаштувати пакет, Дейв Маккі зв’язався зі мною з подібною проблемою та її вирішенням.