Refactoring dei plugin di WordPress: un piccolo esempio

Uno dei modi in cui nascono i plugin di WordPress è che, almeno nel mio caso, iniziano come una raccolta di funzioni utilizzate per aiutare con uno scopo particolare per un determinato progetto. Da lì, pensi "Ehi, forse qualcun altro lo troverà utile".

Almeno questa è stata la mia esperienza il più delle volte.

Ma il fatto è che prima di rilasciarlo per farlo provare ad altre persone, vuoi passare attraverso il processo di pulizia del codice. Non sto nemmeno parlando di refactoring dei plugin di WordPress, almeno non ancora.

Sto parlando di prendere il codice, portarlo a qualcosa che funzionerà come un plugin per WordPress e quindi eventualmente refactoring del codice.

Refactoring dei plugin di WordPress

Passare attraverso l’intero processo di refactoring dei plug-in di WordPress, per non parlare di un singolo plug-in di WordPress, può essere arduo, ma condividere come refactoring una parte di un plug-in è qualcosa che è fattibile.

Quindi userò un esempio di come stavo usando qualcosa di recente (con il codice un po’ astratto in modo da non preoccuparmi di essere specifico su un determinato progetto).

Tracciare l’output ideale delle opzioni.

Prima di farlo, però, penso che sia importante condividere il mio processo potrebbe differire – o probabilmente – differire dal tuo (dal momento che molti di noi hanno processi diversi).

1. Progetta il componente (sì, nemmeno il plug-in completo) in un notebook,
2. Crea una lista di controllo dei casi d’uso in cui dovrebbe passare e quando dovrebbe fallire,
3. Scrivi quali dati sono necessari, come sono necessari e quando dovrebbero essere ignorati
4. Converti tutto quanto sopra in codice.

Ovviamente, non converto tutto letteralmente in codice, ma hai un’idea. Forse il modo più conciso per dirlo è questo:

• Inizia con un metodo lungo che serva al caso d’uso ideale. Quindi rifattorizzare quel codice in modo che le funzioni siano più piccole e tengano conto dei casi in cui il risultato non riuscirebbe.

Detto questo, ecco come potrebbe apparire il codice.

1 Scrivere per il caso d’uso ideale

In questo esempio, il caso d’uso ideale è quando l’utente carica le opzioni, le opzioni sono presenti e quindi deve eseguire un’azione se le opzioni hanno determinati valori.

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

Questa parte dovrebbe essere di facile lettura, ma non tiene conto di nient’altro che del percorso ideale attraverso il codice.

2 Diventa un po’ difensivo

Successivamente, mi piace assicurarmi che le opzioni siano impostate prima di provare a leggerle. In alcuni casi, potresti voler visualizzare un avviso, generare un’eccezione o registrare informazioni.

In questo esempio, tornerò semplicemente perché è facile da leggere e può essere regolato più facilmente per il tuo uso.

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

Quindi questo gestisce le opzioni, ma per quanto riguarda il caso in cui le opzioni sono impostate ma non hanno i valori che ci aspettiamo? Ciò significa che dobbiamo anche verificare che lo facciano. E, in caso contrario, ignorali, restituisci, registra un errore, genera un’eccezione e così via.

Sai: la stessa cosa di cui sopra. Tranne che, in questo caso, non intraprenderò alcuna azione a meno che il codice non abbia l’informazione ideale.

3 Diventare un po’ lunghi

A questo punto, il metodo sta diventando un po’ lungo e sta diventando più difficile da leggere. Certo, se sei un programmatore esperto, puoi affermare che "Questo è codice, non è inglese", ma perché non mirare a renderlo un po’ più facile da seguire?

Inoltre, rende un po’ più facile il test. Ma questo va oltre lo scopo di questo post. Prendi la valutazione delle opzioni come primo esempio del codice.

1. Questo è qualcosa che può essere racchiuso nella sua funzione che non solo isola questo controllo ma rende anche un po’ più semplice la chiamata risultante.
2. Quindi, prendi il secondo blocco di codice che verifica i valori delle opzioni ideali. Questo può anche essere astratto per gli stessi motivi di cui sopra.
3. E infine, imposta una funzione per assicurarti che i valori previsti siano impostati per ciascuno dei valori specificati :

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

Quindi ora hai due metodi più piccoli che incapsulano lo stesso controllo che stavi facendo.

4 La funzione finale

A questo punto, la funzione finale è molto più facile da leggere poiché ha due funzioni di supporto che incapsulano le loro responsabilità mentre questa torna a valutare il percorso ideale attraverso il codice:

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

Basti dire che quando si tratta di refactoring dei plugin di WordPress, questo è solo un esempio di come fare solo un segmento di esso. Ma è un inizio, vero?

Plugin interi?

Infatti, NO? Il refactoring dei plugin di WordPress non è uno scherzo. Ma se inizi con piccole funzioni come questa e procedi gradualmente intorno alla base di codice, diventa più semplice.

E se dedichi del tempo a pianificare il progetto dall’inizio, puoi risparmiare molto tempo tornando indietro e refactoring questo genere di cose.