Non progettare eccessivamente la soluzione

Se provieni da un background orientato agli oggetti o provi a creare tutte le tue soluzioni per WordPress utilizzando tecniche orientate agli oggetti, allora ci saranno momenti in cui potresti sentire come se stessi colpendo un chiodo con una mazza.

Ad esempio, supponiamo che qualcuno venga da te e abbia bisogno di un plug-in personalizzato sviluppato che funzioni con un plug-in di terze parti ma deve solo fare una cosa.

Vale la pena dedicare del tempo alla creazione di un’interfaccia, all’implementazione di detta interfaccia in una classe concreta, alla configurazione degli abbonati, alla scrittura di unit test e così via?

Vedo l’appello, ma in genere dico di no. Se l’essenza di ciò che devi fare deve includere stili o file JavaScript o entrambi, allora perché non fare affidamento sulle API native di WordPress e sulla programmazione procedurale?

Non sovra-ingegnerizzare

Diciamo che un potenziale cliente viene da te che:

• sta lavorando con un budget molto limitato,
• ha un plug-in di terze parti che non si adatta bene al tema,
• ha bisogno solo di uno stile leggero,
• e ha i fondi per contrarre te per il lavoro.

Supponendo che tutto quanto sopra sia vero, direi che elaborare la soluzione sembra abbastanza semplice, giusto? Abbiamo bisogno di controllare il sito in modo da poter:

• determinare la combinazione di colori,
• trovare i selettori necessari per il CSS,
• quindi inizia a creare il plugin.

Ora, quando si tratta di farlo, cerco ancora di utilizzare una manciata di migliori pratiche. Anche se tendo alla programmazione orientata agli oggetti, non la uso sempre né la consiglio sempre.

Invece, penso che l’utilizzo di una semplice funzione o di un insieme di funzioni agganciate all’API di WordPress in modo procedurale funzioni perfettamente. Tuttavia, ciò non significa che non dovremmo mirare a creare una solida struttura organizzativa dei file perché non si sa mai quando potrebbe essere necessario tornare per mantenere il progetto.

A tal fine, ecco cosa faccio normalmente:

• creare una directory degli asset per i fogli di stile e JavaScript (per entrambi o per l’altro, a seconda di ciò che è necessario),
• creare una directory src per il codice che sarà responsabile dell’aggancio a WordPress,
• aggiungi il solito file bootstrap LICENSE, README e plug-in.

La directory risultante potrebbe assomigliare a questa:

Da lì, non mi preoccupo nemmeno di un caricatore automatico. Invece, includo i file nella directory di origine. Puoi scorrere quei file invece di fare qualcosa del genere :

<?php
/**
 * Acme Plugin Example
 *
 * @author    Tom McFarlin <tom@pressware.co>
 * @license   GPL-3.0+
 * @link      https://pressware.co
 * @since     1.0.0
 * @copyright 2018 Tom McFarlin
 *
 * @wordpress-plugin
 * Plugin Name: Acme Plugin Example
 * Description: Provides consistent styling across the site for certain elements.
 * Version:     1.0.0
 * Author:      Tom McFarlin
 * Author URI:  https://tommcfarlin.com
 * License:     GPL-3.0+
 * License URI: http://www.gnu.org/licenses/gpl-3.0.txt
 */

include_once plugin_dir_path(__FILE__).'src/AddStyles.php';
include_once plugin_dir_path(__FILE__).'src/AddScripts.php';

Ma ciò potrebbe dipendere da quando e cosa stai facendo.

Questo è troppo semplice

Forse. Ecco il punto: ogni volta che una persona si radica nell’uso di un certo paradigma di programmazione, detta persona cerca di applicarlo ovunque e cerca di farlo tutto il tempo.

Non tutti, ma molti. Me stesso incluso.

E quando ti ritrovi a progettare qualcosa in modo eccessivo, perché non fare un passo indietro e provare a semplificare un po’ il tuo carico di lavoro?

Il problema è ancora risolto e lo fa in un modo che ha un sovraccarico significativamente inferiore.