Про написання читабельних функцій WordPress

Однією з речей, які я вважаю постійно цікавими (як з точки зору програмування, так і з точки зору WordPress), є ось що:

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

Я думаю, що це очевидно.

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

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

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

Отже, коли справа доходить до створення читабельних функцій WordPress для певного домену, як це може виглядати?

Зрозумілі функції WordPress

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

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

І робити щось заради виконання – це одне, а робити щось заради значущого програмування – інше. Щоразу я вибираю пізніше.

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

Щоб зробити щось подібне, можна виконати такі дії:

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

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

По- перше, виклик Ajax :

$.get(ajaxurl, {
    'action': 'getDetails',
    'security': $('input[name="acme-security-nonce"]').val()
}, function(response) {
    if (false === response.success) {
        // Handle the case when the request wasn't successful.
    }

    // Work with the information that was returned in the response.data property.
});

Потім у нас є функція на стороні сервера для явної перевірки nonce безпеки (це, звичайно, припускає, що ви правильно налаштували його на інтерфейсі):

<?php
/**
 * @return bool true if we're able to make Ajax requests; otherwise, false
 */
private function verifyRequest()
{
    return
        isset($_GET['security']) &&
        wp_verify_nonce(strip_tags(stripslashes($_GET['security'])), 'getDetails');
}

Після цього ми хочемо перевірити, чи існують дані:

<?php

/**
 * @return bool true if there are details; false, otherwise
 *
 * @access private
 */
private function doDetailsExist()
{
    return (new WP_Query([
        'post_type' => 'acme_post_type',
        'post_status' => 'publish',
    ]))->have_posts();
}

Звідси ми можемо працювати з об’єктом відповіді Ajax, оцінюючи його властивість успіху та відповідним чином реагуючи.

Йти на крок далі

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

Зауважте, що це скоріше вправа показу того, як щось зробити, а не сперечання щодо використання $wpdb над WP_Query. Це вміст для зовсім іншої публікації.

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

<?php
/**
 * @return array a numerically indexed array of all detail IDs
*/
private function getDetailIds(): array
{
    global $wpdb;
    $results = $wpdb->get_results(
        $wpdb->prepare("
        SELECT meta_value
        FROM $wpdb->postmeta
        WHERE meta_key = %s
        ORDER BY meta_value ASC
        ", 'acme_detail_number'),
        ARRAY_N
    );

    $detailIds = [];
    array_push($detailIds, array_map(function ($result) {
        return $result[0];
    }, $results));

    return $detailIds[0] ?? $detailIds;
}

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

Яка мета всього цього?

Загалом, це допомагає нам думати про код таким чином, щоб ми могли читати його майже якомога ближче до написаного. Тобто ми можемо вказати на фрагмент коду, наприклад:

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

Звичайно, я говорю тут менш конкретно, але це тому, що я не обов’язково знаю, з чим ви працюєте, не більше, ніж ви знаєте про мою роботу. Але ви зрозуміли ідею, правда?

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

Але, як і у випадку з деякими пунктами, згаданими вище, це тема для іншої публікації.

Зараз я пишу електронну книгу (разом із різноманітним іншим преміум-контентом). Якщо вам цікаво, перевірте, що ви отримуєте.