Бібліотеки для плагінів WordPress, частина 1
Чим більше ви працюєте з WordPress, особливо якщо ви використовуєте такі інструменти, як Composer тощо, тим більше ймовірностей, що ви знайдете певні бібліотеки, інструменти та подібні речі, які формують основу проектів, над якими ви працюєте.
Іноді ви можете знайти їх під час перегляду коду інших людей, можливо, ви знайдете їх під час перегляду GitHub, або, можливо, хтось, з ким ви працюєте, запропонує бібліотеку (або декілька) залежно від проекту.
Особисто я мав досвід усього вищезазначеного, і чим більше я працюю над розробкою рішень для себе чи інших, тим більше я вважаю, що встановлюю ту саму основу для кожного проекту (як правило, якийсь плагін) .
Бібліотеки для плагінів WordPress
З цією метою я подумав, що варто поділитися бібліотеками, які я використовую під час створення плагінів WordPress. Вміст буде розподілено між кількома публікаціями, щоб кожне було коротким і зосередженим, але, можливо, ви знайдете щось, чим раніше не користувалися (або це покращить ваше поточне використання).
PHPUnit
Кожен, хто писав будь-який код на будь-якій мові програмування, швидше за все, знайомий з будь-яким типом бібліотеки *Unit. Коротше кажучи, це спосіб легко писати модульні тести.
З домашньої сторінки проекту :
PHPUnit — це платформа для тестування PHP, орієнтована на програміста. Це екземпляр архітектури xUnit для фреймворків модульного тестування.
Я не з тих, хто обов’язково погоджується на 100% покриття коду (і це тема для іншої публікації), але якщо ви збираєтеся писати модульні тести, то це дефакто бібліотека для модульного тестування вашого коду.
GrumPHP
Протягом цього року GrumPHP став, мабуть, моєю улюбленою бібліотекою (хоча її покращили додаткові бібліотеки, про які я розповідатиму в цій серії публікацій).
Я говорив про це в інших публікаціях. Хоча він описує себе як «інструмент якості коду», ви дійсно не можете не помітити переваги, доки не підключите його, щоб спостерігати за своїм кодом, перш ніж спробувати закріпити його в репозиторії.
Довший опис:
Якщо тести не пройдуть, ви не зможете зафіксувати свої зміни. Цей зручний інструмент не тільки покращить вашу кодову базу, він також навчить ваших колег писати кращий код, дотримуючись найкращих практик, які ви визначили як команда.
І так само, як якщо б ви використовували будь-який монітор стандартів кодування у своїй IDE, це одна з тих речей, використання яких спочатку може бути неприємним.
Але коли ви його вивчаєте, стає легше знати, що він позначатиме, тому ви автоматично починаєте писати код вищого рівня якості.
PHPMD
PHPMD (скорочення від PHP Mess Detector) добре працює в поєднанні з GrumPHP, оскільки він може обробити ваш код перед тим, як ви надішлете його в репозиторій.
Сам проект описує себе так:
Він бере задану базу вихідного коду PHP і шукає кілька потенційних проблем у цьому джерелі.
Як і у випадку з багатьма подібними бібліотеками, ця конкретна бібліотека може налаштувати набір правил, щоб ви могли легко вмикати та вимикати щось залежно від того, що ви або ваша команда віддаєте перевагу.
PHP-парсер
Ідея встановлення бібліотеки синтаксичного аналізатора PHP для аналізу вашого коду здається трохи метаграфічною, чи не так? Я маю на увазі, що у вас є середовище виконання PHP, яке робить це, і багато IDE також роблять це, але це працює дещо по-іншому.
Зі сховища:
Це аналізатор PHP 5.2 до PHP 7.1, написаний на PHP. Його мета — спростити статичний аналіз коду та маніпуляції.
Для тих, хто знайомий з тим, як працюють мови програмування (і, отже, граматики), ідея статичного аналізу коду матиме сенс.
Незважаючи на це, це ще одна бібліотека, яка допомагає покращити якість коду шляхом зменшення складності коду.
Буде більше
Наприкінці серії я розповім, як об’єднати все це у composer.jsonфайл, який можна використовувати у своєму проекті.
Коли ви працюєте над рішенням для клієнта, можливо, вам доведеться змінити версії кожного з цих інструментів, але ви побачите, що більшість із них пропонують підтримку від PHP5.6 до PHP7.1.