Віджети WordPress: рефакторинг, частина 1

Останній допис містив багато інформації про налаштування інструментів якості коду у вашому середовищі розробки WordPress, але вони необхідні, якщо ми збираємося робити багато рефакторингу.

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

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

Незважаючи на це, попередня публікація показує, скільки роботи ми виклали для себе, чи не так?

Тепер ми почнемо з рефакторингу WordPress Widget Boilerplate.

Це не тільки покращить якість коду, але й допоможе нам ознайомитися з деякими об’єктно-орієнтованими принципами, які ми можемо застосувати під час створення наших віджетів і ми зможемо застосувати в майбутніх зусиллях розробки WordPress.

Шаблон віджета WordPress: рефакторинг, частина 1

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

Цій речі шість років (на момент публікації).

Це довго за роки Інтернету, чи не так?

У будь-якому разі, у наших зусиллях з рефакторингу ми збираємося зробити деякі речі:

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

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

1 Створення гілки розвитку

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

Найкраще не працювати над головною гілкою. Натомість для розгортання останньої стабільної версії коду завжди слід використовувати майстер.

Для цього введіть таку команду у свій термінал:

$ git checkout -b develop

Це створить нову місцеву філію. Його ще не передано на GitHub або у ваш віддалений репозиторій (де б ви його не зберігали).

Далі введіть таку команду:

$ git push --set-upstream origin develop

Це підштовхне гілку розробки до віддаленого сховища. Коли це буде зроблено, ви зможете побачити всі зміни, внесені в останньому дописі, у вашому віддаленому сховищі.

Якщо ви використовуєте GitHub, це має виглядати приблизно так:

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

Примітка про філію

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

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

2 Реорганізація файлів

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

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

Оновлення каталогів

Одна з речей, які я намагаюся зробити, це розбити свої каталоги, щоб вони були якомога зрозумілішими. Це означає, що я намагаюся робити наступне:

• створити каталог активів для JavaScript і таблиць стилів,
• створити каталог src для всіх файлів PHP,
• створити мовний каталог для файлів інтернаціоналізації,
• зберігайте всі інші файли в корені сховища, щоб іншим було легко слідкувати за наданим файлом README.

Для цього я збираюся спочатку видалити та перемістити кілька речей. Я спробував організувати це в певному порядку:

1. Я збираюся видалити файл README.txt. Цей файл використовується як стандартний шаблон README, якщо ви збираєтеся надсилати код до репозиторію плагінів WordPress, але він не є необхідним для того, що я хочу для Boilerplate.
2. Я перейменую plugin.php на Plugin .php відповідно до конвенцій PSR.
3. Я також перейменую lang на мови.
4. Я збираюся створити каталог ресурсів і перемістити, а потім перемістити каталоги css і js у цей каталог. Я створю підкаталог dev у кожному з цих каталогів, де ми зможемо працювати над файлами Sass і немініфікованими JavaScript (обидва з’являться пізніше в серії).
5. Після цього я створю каталог src і перемістю таблицю стилів представлень у цей каталог.
6. Я також перейменую Views на Views, а файли, що містяться в ньому, будуть написані великими літерами.
7. Нарешті, я перенесу все до кореня каталогу. Це означає , що шаблонний віджет зникне, а всі файли будуть зберігатися в кореневому каталозі сховища.

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

Видаліть файл README

Щоб зробити це, просто введіть наступну команду у вашому терміналі з кореневого каталогу widget-boilerplate :

$ rm readme.txt

Це видалить файл. Якщо ви введете таку команду у своєму терміналі:

$ git status

Ви повинні побачити щось на зразок цього:

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

Введіть наступні:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Це накаже Git видалити файл, додати єдину зміну до набору змін, зафіксувати її без запуску будь-яких інструментів якості коду (оскільки нам не потрібно робити це прямо зараз, інакше це не вдасться) і натисне її до гілки розробки віддаленого сховища .

Тепер, коли ми це зробили, давайте перейменуємо деякі файли.

Перейменування файлів

Поки ми на цьому, ми збираємося не лише перейменувати файл плагіна .php, а й інші файли PHP. Це файли, які можна логічно згрупувати в одному наборі змін, тому має сенс це зробити.

Отже, у вашому терміналі введіть такі команди:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

Роблячи це, ми ще не вносили жодних змін у файли, тому нема чого фіксувати. Перейменуємо каталоги.

Створення каталогів; Перейменувати каталоги

Так само, як ми зробили з файлами, давайте створимо новий каталог ресурсів . У вашому терміналі введіть таку команду:

$ mkdir assets

Далі ми хочемо перемістити каталоги css і js у цей каталог, тому також введіть наступне в терміналі:

$ mv css assets
$ mv js assets

І давайте перейменуємо каталог lang на Languages, ввівши таку команду:

$ mv lang Languages

Нарешті, давайте перейменуємо View на Views:

$ mv views Views

На даний момент ми зробили все можливе з файлами, які зараз знаходяться в головному каталозі. Однак нам все ще потрібно підготувати підкаталоги для наших попередньо оброблених ресурсів.

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

У цьому випадку я вважаю, що можна додати все в один набір змін із коментарем, який вказує, що ми перейменували та перемістили файли.

Ви можете відрізнятися, і якщо так, то це цілком нормально. Ваші команди дещо відрізнятимуться від моїх, але ось що я маю для свого коміту:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Тепер перейдемо до підкаталогів для наших попередньо оброблених файлів.

Створення підкаталогів

У каталозі CSS створіть підкаталог під назвою dev і створіть порожній файл під назвою admin.scss і widget.scss, оскільки ми будемо працювати з цими файлами пізніше в серії.

Далі додайте каталог dev до каталогу JavaScript і додайте до цих файлів порожній файл admin.js і файли widget.js . Якщо ви відчуваєте таке бажання, ви можете перемістити існуючі файли в каталоги dev, оскільки це файли, які ми будемо використовувати як основу для наших файлів розробки.

Це необов’язковий крок; однак я пішов вперед і зробив це, тому що саме так мені подобається працювати. Ось набір команд, які я виконав.

З каталогу css …

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Вище я створив каталог dev для своїх таблиць стилів, перейменував їх у файли Sass і перемістив у каталог dev.

Перш ніж рухатися вперед, нехай зараз саме час перевірити статус git і зафіксувати зміни, пов’язані з таблицями стилів:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Тепер із каталогу js …

$ mkdir dev
$ mv *.js dev

Оскільки нам не потрібно змінювати тип пов’язаних файлів, ми можемо просто перемістити їх у новий каталог.

Нарешті, давайте зробимо те ж саме і перевіримо, чи є якісь зміни, які ми можемо просунути через швидку перевірку стану git (яка має бути). Ось список команд, які я запустив, щоб зафіксувати та надіслати свої зміни:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

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

Перемістіть каталоги в корінь

По суті, нам потрібно перемістити все, крім файлу плагіна та каталогу Views, з каталогу widget-boilerplate, і нам потрібно перейменувати widget-boilerplate на src.

Звучить просто, правда? Це досить просто. З каталогу widget-boilerplate :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Потім я зафіксую зміни в GitHub за допомогою наступного:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Тепер ми маємо набагато сучаснішу структуру каталогу. Ви можете побачити це тут, у моїй гілці розробки.

Кілька слів про ООП

І тепер, коли ми все це підготували, ми можемо почати писати код. Але не помиляйтеся: частина об’єктно-орієнтованого програмування також є об’єктно-орієнтованим аналізом і об’єктно-орієнтованим проектуванням.

У цьому дописі ми, по суті, застосували об’єктно-орієнтований архітектурний дизайн на основі аналізу того, як плагін поєднується.

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

У наступному дописі

Основна мета наступної публікації — продовжити оновлення стандартів кодування, щоб ми вирішили всі проблеми, які виникли через нашу IDE або через інструменти якості коду, які ми запускаємо в командному рядку.

Ми також повинні мати набагато чистіший, більш організований репозиторій і мати можливість об’єднати нашу роботу назад у головну гілку.

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