Використання PSR (у порівнянні зі стандартами кодування WordPress)

На даний момент я не знаю, скільки статей я написав про важливість стандартів кодування WordPress (достатньо, щоб посилатися на них тут, тут і тут, я думаю, що щось має значення).

Але після виконання достатньої кількості проектів для клієнтів і роботи з розробниками, які набагато розумніші та знайомі з розширеними інструментами, ніж я, я досяг того місця, де я вирішив почати використовувати PSR у розробці WordPress WordPress.

О, драма, чи не так?

Але серйозно. На це є причини, і іноді я вважаю, що стандарти кодування WordPress все ще повинні використовуватися, але я швидко переконуюся, що для створення будь-якого сучасного проекту на основі WordPress слід використовувати більш сучасні інструменти PHP (які я коротко згадаю пізніше).

Використання PSR у розробці WordPress

Подібні дописи часто викликають дебати чи різку реакцію в WordPress, що не є моїм наміром і не є чимось, що я вважаю навіть необхідним. Чесно кажучи, я знаю чимало інших розробників , які зробили це давно, говорили про це, рухалися вперед і продовжували досягати успіху як у своєму бізнесі, так і в своїх проектах-хобі.

Але враховуючи те, що я так багато говорив про одне проти іншого, я подумав, що варто поділитися своїм баченням того, чому я вирішив зробити цю зміну зараз, і обґрунтування цього.

1 Паритет із спільнотою PHP

Приблизно за останній рік і лише за останні кілька місяців цього року я більше звик до:

• більш досвідчені друзі-розробники, орієнтовані на PHP, які схвалюють інструменти, які очікують прийняття PSR,
• використання //@codingStandardsIgnoreStart і //@codingStandardsIgnoreEnd у моєму коді,
• спеціальні набори правил для моїх проектів на основі середовищ, у яких вони розгорнуті,
• і більше.

Зрештою, мова йде про бажання підтримувати паритет (або частково) з більшою спільнотою PHP загалом, а також писати читабельний код на основі стандартів поверх WordPress. І я також хотів би використовувати деякі інші інструменти та новіші версії існуючих інструментів (про які я розповім пізніше в цій публікації).

2 Проблеми сучасного середовища

На момент написання цієї публікації PHP CodeSniffer (який необхідний для запуску стандартів кодування WordPress) має версію 3.0.2. Однак існують проблеми сумісності з PHPCS і зі стандартами кодування WordPress. Зокрема :

У новій версії PHP CodeSniffer є кілька приємних функцій, але внесені критичні зміни, які означають, що стандарти кодування WordPress несумісні.

Щоб було зрозуміло (і через природу програмного забезпечення), це питання часу, перш ніж це буде виправлено. Але якщо ви працюєте над кодовою базою та використовуєте Composer і стандарти кодування WordPress, вам потрібно буде явно встановити версію PHP CodeSniffer, а не будь-яку останню версію на даний момент.

Крім того, у мене були проблеми з клієнтами, коли я не використовував PSR у розробці WordPress, що призводило до дивної поведінки під час розгортання коду. Можливо, вони повинні змінити середовище, але якщо вони працюють над тим, щоб мати найсучасніші інструменти, доступні людям, які ними користуються, навіщо регресувати?

3 Сумісність із сучасними інструментами

Нарешті, є низка сучасних інструментів, якими я не міг скористатися, не кажучи вже про те, що не зміг навчитися, через те, що підтримується, а що не підтримується природою керування версіями.

Наприклад, ми використовували GrumPHP у недавньому проекті, який підтримує різноманітні інструменти, але ми не змогли використати, скажімо, PHPMD через відсутність адаптації PSR. Наскільки я можу судити:

• Я хочу постійно вдосконалювати свої навички розробника (і, в цьому контексті, розробника PHP),
• відсутність підтримки сучасніших інструментів ставить мене в патерн утримування, якого я б інакше не відчув,
• Я хочу продовжувати працювати з WordPress, але робити це з більш сучасним робочим процесом

І саме зараз невикористання PSR створює розрив між тим, що робить інша спільнота PHP, і тим, що робить WordPress. Тож я хотів би рухатися вперед, продовжуючи працювати над проектами на програмному забезпеченні, яким я все ще люблю користуватися.

Що щодо стандартів кодування WordPress

Отже, що це означає щодо стандартів кодування WordPress і попередніх публікацій? Нічого, насправді. На мій погляд: Стандарти кодування WordPress слід використовувати щоразу, коли ви працюєте над WordPress Core або чимось, що буде тісно в нього інтегровано.

Але якщо ви працюєте над чимось, що стоїть поверх WordPress, або над тим, що використовує WordPress як основу, ви можете використовувати PSR у розробці WordPress разом із інструментами, які можуть допомогти підвищити якість кодової бази, яку ви створюєте.

Тож, принаймні на даний момент, це та перспектива, яку я збираюся прийняти. Я дуже хочу побачити, як це розвиватиметься протягом наступних кількох місяців. І що стосується всього іншого, чим я поділився, я розповім про аспекти здійснення цього перемикання.