Рефакторинг плагінів WordPress: невеликий приклад
Одним із способів появи плагінів WordPress є те, що, принаймні в моєму випадку, вони починаються як набір функцій, які використовуються для допомоги з певною метою для певного проекту. Звідти ви думаєте: «Гей, можливо, комусь ще це стане в нагоді».
Принаймні це був мій досвід частіше, ніж ні.
Але справа в тому, що перед тим, як випустити його для інших людей, ви хочете пройти процес очищення коду. Я також не кажу про рефакторинг плагінів WordPress – принаймні поки.
Я говорю про те, щоб взяти код, привести його до чогось, що працюватиме як плагін WordPress, а потім, можливо, змінити код.
Рефакторинг плагінів WordPress
Пройти весь процес рефакторингу плагінів WordPress – не кажучи вже про один плагін WordPress – може бути складно, але поділитися тим, як рефакторинг частини плагіна – це те, що можливо.
Тож я використаю приклад того, як нещодавно використовував щось (з дещо абстрагованим кодом, щоб не турбуватись детальніше про будь-який проект).
Складання діаграми ідеального виходу опціонів.
Однак перед тим, як це зробити, я вважаю важливим поділитися тим, що мій процес може відрізнятися – або ймовірно – відрізняється від вашого (оскільки багато з нас мають різні процеси).
- Створіть компонент (так, навіть не повний плагін) у блокноті,
- Створіть контрольний список випадків використання, в яких він повинен проходити, а коли він повинен виходити з ладу,
- Напишіть, які дані потрібні, як вони потрібні, а коли їх слід ігнорувати
- Перетворіть усе вищезазначене на код.
Звичайно, я не перетворюю все це буквально на код, але ви зрозуміли ідею. Мабуть, найстисліший спосіб висловити це так:
- Почніть із тривалого методу, який є ідеальним варіантом використання. Потім відрефакторіть цей код, щоб функції були меншими та враховували випадки, коли результат буде невдалим.
Отже, ось як може виглядати код.
1 Написання для ідеального використання
У цьому прикладі ідеальний варіант використання — це коли користувач завантажує параметри, параметри присутні, а потім йому потрібно виконати дію, якщо параметри мають певні значення.
<?php
private function load_dates() {
$options = get_option( 'acme_date_options' );
$event_settings = $options['event'];
$import = $event_settings['import'];
$post_type = $event_settings['post-type'];
if (( 0 === strcmp( 'yes', $import)) && (0 === strcmp( 'events', $post_type) )) {
// This is where you take whatever action you want.
}
}
Ця частина має бути легкою для читання, але вона не враховує нічого, крім ідеального шляху через код.
2 Будьте трохи оборонними
Далі я хочу переконатися, що параметри встановлено, перш ніж спробувати їх прочитати. У деяких випадках вам може знадобитися відобразити сповіщення, створити виняток або зареєструвати інформацію.
У цьому прикладі я просто повернуся, оскільки його легко читати та його найлегше налаштувати для використання.
<?php
private function load_dates() {
$options = get_option( 'acme_date_options' );
if (! isset( $options['event'])) {
return;
}
$event_settings = $options['event'];
if (! isset( $event_settings['import']) ||! isset( $event_settings['post-type'])) {
return;
}
$import = $event_settings['import'];
$post_type = $event_settings['post-type'];
if (( 0 === strcmp( 'yes', $import)) && (0 === strcmp( 'events', $post_type) )) {
// This is where you take whatever action you want.
}
}
Отже, це обробляє параметри, але як щодо випадку, коли параметри встановлені, але не мають значень, які ми очікуємо? Це означає, що нам також потрібно перевірити, чи вони це роблять. А якщо ні, ігноруйте їх, повертайтеся, реєструйте помилку, створюйте виняток тощо.
Ви знаєте: те саме, що й вище. За винятком того, що в цьому випадку я не збираюся вживати жодних дій, якщо код не містить ідеальної інформації.
3 Трохи подовжимо
На цьому етапі метод стає трохи довгим і стає важчим для читання. Звісно, якщо ви досвідчений програміст, ви можете стверджувати, що «Це код, він не англійський», але чому б не спробувати зробити його трохи легшим для наслідування?
Крім того, це трохи полегшує тестування. Але це виходить за рамки цієї публікації. Розглянемо оцінку параметрів як перший приклад коду.
- Це те, що можна загорнути в його функцію, яка не тільки ізолює цю перевірку, але й спрощує кінцевий виклик.
- Далі візьміть другий блок коду, який перевіряє ідеальні значення параметрів. Це також можна абстрагувати з тих самих причин, наведених вище.
- І, нарешті, налаштуйте функцію, щоб переконатися, що очікувані значення встановлені для кожного з указаних значень :
<?php
private function has_valid_option( $option) {
return isset( $option );
}
private function has_valid_values( $value1, $value2) {
return! (isset( $value1) && isset( $value2) );
}
private function can_import_data( $value1, $value2) {
return (0 === strcmp( 'yes', $value1)) && (0 === strcmp( 'events', $value2) );
}
Отже, тепер у вас є два менших методи інкапсуляції тієї самої перевірки, яку ви робили.
4 Остаточна функція
На цьому етапі остаточну функцію набагато легше прочитати, оскільки вона має дві допоміжні функції, які інкапсулюють свої обов’язки, а ця повертається до оцінки ідеального шляху через код:
<?php
private function load_dates() {
$options = get_option( 'acme_date_options' );
if (! $this->has_valid_option( $options)) {
return;
}
$event_settings = $options['event'];
if (! $this->has_valid_values( $event_settings['import'], $event_settings['post-type'])) {
return;
}
$import = $event_settings['import'];
$post_type = $event_settings['post-type'];
if ($this->can_import_data( $import, $post_type)) {
// This is where you take whatever action you want.
}
}
Достатньо сказати, що коли мова йде про рефакторинг плагінів WordPress, це лише один приклад того, як зробити лише його сегмент. Але це початок, чи не так?
Цілі плагіни?
я знаю, правда? Рефакторинг плагінів WordPress – це не жарт. Але якщо ви починаєте з таких невеликих функцій і поступово працюєте над кодовою базою, це стає легше.
І якщо ви витрачаєте час на планування проекту з самого початку, це може заощадити багато часу, повертаючись назад і рефакторинг такого роду речей.