Refactoring des plugins WordPress : un petit exemple

L’une des façons dont les plugins WordPress se présentent est que, du moins dans mon cas, ils commencent comme un ensemble de fonctions utilisées pour aider à un objectif particulier pour un projet donné. À partir de là, vous pensez "Hé, peut-être que quelqu’un d’autre trouvera cela utile."

Au moins, c’est mon expérience plus souvent qu’autrement.

Mais le fait est qu’avant de le publier pour que d’autres personnes l’essaient, vous devez passer par le processus de nettoyage du code. Je ne parle pas non plus de refactoriser les plugins WordPress – du moins pas encore.

Je parle de prendre le code, de l’amener à quelque chose qui fonctionnera comme un plugin WordPress, puis éventuellement de refactoriser le code.

Refactorisation des plugins WordPress

Passer par l’ensemble du processus de refactorisation des plugins WordPress – sans parler d’un seul plugin WordPress – peut être ardu, mais partager comment refactoriser une partie d’un plugin est quelque chose de faisable.

Je vais donc utiliser un exemple de la façon dont j’utilisais quelque chose récemment (avec le code abstrait un peu pour ne pas prendre la peine de préciser un projet donné).

Tracer la sortie idéale des options.

Avant de le faire, cependant, je pense qu’il est important de partager mon processus peut différer – ou probablement – différer du vôtre (puisque beaucoup d’entre nous ont des processus différents).

1. Concevoir le composant (oui, même pas le plugin complet) dans un notebook,
2. Établissez une liste de contrôle des cas d’utilisation dans lesquels il devrait réussir et quand il devrait échouer,
3. Écrivez quelles données sont nécessaires, comment elles sont nécessaires et quand elles doivent être ignorées
4. Convertissez tout ce qui précède en code.

Bien sûr, je ne convertis pas tout cela littéralement en code, mais vous voyez l’idée. Peut-être que la façon la plus succincte de le dire est la suivante :

• Commencez par une longue méthode qui sert le cas d’utilisation idéal. Ensuite, refactorisez ce code afin que les fonctions soient plus petites et tiennent compte des cas dans lesquels le résultat échouerait.

Cela dit, voici à quoi pourrait ressembler le code.

1 Écrire pour le cas d’utilisation idéal

Dans cet exemple, le cas d’utilisation idéal est lorsque l’utilisateur charge les options, les options sont présentes, puis il doit effectuer une action si les options ont certaines valeurs.

<?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.
    }
}

Cette partie devrait être facile à lire, mais elle ne tient compte que du chemin idéal dans le code.

2 Soyez un peu défensif

Ensuite, j’aime m’assurer que les options sont définies avant d’essayer de les lire. Dans certains cas, vous souhaiterez peut-être afficher un avis, lever une exception ou consigner des informations.

Dans cet exemple, je vais juste revenir car il est facile à lire et peut être plus facilement ajusté pour votre usage.

<?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.
    }
}

Donc, cela gère les options, mais qu’en est-il du cas où les options sont définies mais n’ont pas les valeurs que nous attendons ? Cela signifie que nous devons également vérifier qu’ils le font. Et, si ce n’est pas le cas, ignorez-les, retournez, enregistrez une erreur, lancez une exception, etc.

Vous savez: La même chose que ci-dessus. Sauf que, dans ce cas, je n’entreprendrai aucune action à moins que le code ne contienne l’information idéale.

3 Devenir un peu long

À ce stade, la méthode devient un peu longue et devient plus difficile à lire. Bien sûr, si vous êtes un programmeur expérimenté, vous pouvez faire valoir que "C’est du code, ce n’est pas de l’anglais", mais pourquoi ne pas viser à le rendre un peu plus facile à suivre ?

De plus, cela facilite un peu le test. Mais cela dépasse le cadre de cet article. Prenons l’évaluation des options comme premier exemple du code.

1. C’est quelque chose qui peut être enveloppé dans sa fonction qui non seulement isole cette vérification, mais rend également l’appel résultant un peu plus facile.
2. Ensuite, prenez le deuxième bloc de code qui vérifie les valeurs d’option idéales. Cela peut également être abstrait pour les mêmes raisons ci-dessus.
3. Et enfin, configurez une fonction pour vous assurer que les valeurs attendues sont définies pour chacune des valeurs spécifiées :

<?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) );
}

Vous avez donc maintenant deux méthodes plus petites encapsulant la même vérification que vous faisiez.

4 La fonction finale

À ce stade, la fonction finale est beaucoup plus facile à lire car elle comporte deux fonctions d’assistance qui encapsulent leurs responsabilités tandis que celle-ci revient à évaluer le chemin idéal à travers le code :

<?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.
    }
}

Qu’il suffise de dire que lorsqu’il s’agit de refactoriser les plugins WordPress, ce n’est qu’un exemple de la façon d’en faire juste un segment. Mais c’est un début, non ?

Des plugins entiers ?

N’est-ce pas? Refactoriser les plugins WordPress n’est pas une blague. Mais si vous commencez avec de petites fonctions comme celle-ci et progressez progressivement dans la base de code, cela devient plus facile.

Et si vous passez du temps à planifier le projet dès le départ, cela peut vous faire gagner beaucoup de temps en revenant en arrière et en refactorisant ce genre de choses.