Widget WordPress: refactoring, parte 1

L’ultimo post include molte informazioni sulla configurazione degli strumenti di qualità del codice nel tuo ambiente di sviluppo WordPress, ma sono necessari se faremo molto refactoring.

Ma come ho detto all’inizio di questo post, la creazione di strumenti per la qualità del codice ci fornisce innanzitutto una base che possiamo utilizzare durante il refactoring del boilerplate (cosa che dobbiamo chiaramente fare data la quantità di rosso mostrata da GrumPHP).

Onestamente, li vedo come necessari se hai intenzione di fare qualsiasi tipo di sviluppo, da qui la necessità di mostrare come configurarli.

Indipendentemente da ciò, il post precedente mostra quanto lavoro abbiamo ritagliato per noi, giusto?

Ora inizieremo con il refactoring di WordPress Widget Boilerplate.

Ciò non solo migliorerà la qualità del codice, ma ci guiderà anche attraverso alcuni principi orientati agli oggetti che possiamo applicare durante la creazione dei nostri widget e che possiamo applicare nei futuri sforzi di sviluppo di WordPress.

The WordPress Widget Boilerplate: Refactoring, Parte 1

Forse la cosa più eccitante per me è portare questo repository agli standard moderni. Se guardi il ramo principale in GitHub al momento di questo post (o la cronologia del repository in seguito), vedrai che ha sei anni.

Questa cosa ha sei anni (al momento di questo post).

È molto tempo negli anni di Internet, non è vero?

Ad ogni modo, nei nostri sforzi di refactoring, faremo alcune cose:

• creare un ramo su cui lavorare prima di unirlo nuovamente al ramo principale,
• implementare un modo più coerente di organizzare i file,
• aggiornare gli standard di codifica per seguire ciò che è più in linea con PSR,
• e altro ancora.

Lo spiego ora perché probabilmente non lo raggiungeremo tutto in questo post, ma tratteremo molto terreno. Quindi, detto questo, iniziamo.

1 Creazione di un ramo di sviluppo

Supponendo che tu abbia una copia del repository di sulla tua macchina locale, che dovresti avere dopo l’ultimo post, la prima cosa che dobbiamo fare è creare un ramo di cui fare il nostro lavoro.

È buona norma non lavorare sul ramo principale. Invece, il master dovrebbe sempre essere usato per distribuire l’ultima versione stabile del codice.

A tal fine, inserisci il seguente comando nel tuo terminale:

$ git checkout -b develop

Questo creerà una nuova filiale locale. Non è ancora stato inviato a GitHub o al tuo repository remoto (ovunque tu lo stia conservando).

Quindi, inserisci il seguente comando:

$ git push --set-upstream origin develop

Questo spingerà il ramo di sviluppo fino al repository remoto. Una volta fatto, dovresti essere in grado di vedere tutte le modifiche che abbiamo implementato nell’ultimo post nel tuo repository remoto.

Se stai usando GitHub, dovrebbe assomigliare a questo:

Se stai utilizzando un altro servizio, dovrebbe comunque essere simile. Cioè, la struttura della directory dovrebbe essere la stessa, ma l’aspetto nel browser varierà.

Una nota sul ramo

Ricorda, lo scopo di questo ramo è che facciamo tutto il nostro lavoro. In questo modo, non stiamo interferendo con il ramo principale da cui molte persone attireranno.

Per essere chiari, forse nessuno tirerà fuori da questo. Forse lo faranno. Indipendentemente da ciò, queste pratiche introdotte qui hanno lo scopo di mostrare come eseguire un progetto utilizzando il controllo del codice sorgente e strumenti di qualità del codice in modo da poter creare progetti migliori per te, la tua azienda e altro ancora.

2 Riorganizzazione dei file

La prima cosa che dovremmo fare è riorganizzare i file, in modo che imitino una struttura più moderna. Farò del mio meglio per giustificare le decisioni che sto prendendo per il progetto mentre lo facciamo; tuttavia, sentiti libero di prenderti delle libertà su come vuoi farlo.

Le decisioni che prendo alla fine influenzeranno il Boilerplate primario. Ciò che scegli di fare influenzerà il modo in cui puoi utilizzarlo nel tuo lavoro quotidiano o come scegli di andare avanti con il progetto nel suo insieme.

Aggiornamento delle directory

Una delle cose che provo a fare è scomporre le mie directory, in modo che siano il più chiare possibile. Ciò significa che provo a fare quanto segue:

• creare una directory degli asset per JavaScript e fogli di stile,
• creare una directory src per tutti i file PHP,
• creare una directory della lingua per i file di internazionalizzazione,
• mantieni tutti gli altri file nella radice del repository, quindi è facile per gli altri seguirli insieme al README fornito.

Per fare ciò, prima rimuoverò e sposterò alcune cose. Ho provato a organizzare questo in un ordine particolare:

1. Rimuoverò il file README.txt. Questo file viene utilizzato come modello README standard se intendi inviare codice al WordPress Plugin Repository, ma non è necessario per quello che voglio per Boilerplate.
2. Rinominerò plugin.php in Plugin .php per seguire le convenzioni PSR.
3. Rinominerò anche lang in lingue.
4. Creerò una directory di asset e sposterò e quindi sposterò le directory css e js in quella directory. Creerò una sottodirectory dev in ciascuna di queste directory in cui possiamo lavorare su Sass e file JavaScript non minimizzati (entrambi arriveranno più avanti nella serie).
5. Successivamente, creerò una directory src e sposterò il foglio di stile delle viste in quella directory.
6. Rinominerò anche le viste in Visualizzazioni e metterò in maiuscolo anche i file in esso contenuti.
7. Infine, sposterò tutto nella radice della directory. Ciò significa che widget-boilerplate scomparirà e tutti i file risiederanno nella directory principale del repository.

Questi sono molti passaggi, ma sono piccoli. Mi piace disporli prima in modo che sia chiaro cosa accadrà nel resto di questa sezione.

Rimuovere il LEGGIMI

Per fare ciò, inserisci semplicemente il seguente comando nel tuo terminale dalla radice della directory widget-boilerplate :

$ rm readme.txt

Questo rimuoverà il file. Se inserisci il seguente comando nel tuo terminale:

$ git status

Dovresti vedere qualcosa del genere:

Sono un fan dell’assicurarmi che le varie modifiche apportate siano chiare e concise in modo che sia più facile ripristinarle una alla volta. Quindi andiamo avanti e impegniamoci e spingiamo questo cambiamento.

Digita il seguente:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Questo dirà a Git di rimuovere il file, aggiungere la singola modifica al set di modifiche, eseguirne il commit senza eseguire alcuno strumento di qualità del codice (perché non è necessario farlo in questo momento, altrimenti fallirà) e lo spingerà al ramo di sviluppo del repository remoto .

Ora che abbiamo fatto, andiamo avanti e rinominiamo alcuni file.

Rinominare i file

Già che ci siamo, non solo rinomineremo il file plugin .php ma anche gli altri file PHP. Questi sono file che possono essere raggruppati logicamente nello stesso set di modifiche, quindi ha senso andare avanti e farlo.

Quindi dal tuo terminale, inserisci i seguenti comandi:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

In questo modo, non abbiamo ancora apportato modifiche ai file, quindi non c’è nulla da confermare. Andiamo avanti con la ridenominazione delle directory.

Creare directory; Rinomina directory

Proprio come abbiamo fatto con i file, andiamo avanti e creiamo una nuova directory degli asset. Nel tuo terminale, inserisci il seguente comando:

$ mkdir assets

Successivamente, vogliamo spostare le directory css e js in quella directory, quindi inserire anche quanto segue nel terminale:

$ mv css assets
$ mv js assets

E rinominiamo la directory lang in Lingue inserendo il seguente comando:

$ mv lang Languages

Infine, rinominiamo la vista in Visualizzazioni:

$ mv views Views

A questo punto, abbiamo fatto tutto il possibile con i file attualmente nella directory principale. Tuttavia, dobbiamo ancora preparare le sottodirectory per le nostre risorse preelaborate.

Prima di farlo, tuttavia, è una buona abitudine eseguire un rapido controllo dello stato di git per vedere cosa esiste che può essere aggiunto a un changeset. Se il tuo repository è come il mio, è probabile che vedrai qualcosa di simile al seguente:

In questo caso, penso che sia giusto aggiungere tutto in un unico changeset con un commento che indica che abbiamo rinominato e spostato i file.

Potresti essere diverso e, in tal caso, va benissimo. I tuoi comandi saranno leggermente diversi dai miei, ma ecco cosa ho per il mio commit:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Ora, alle sottodirectory per i nostri file preelaborati.

Crea sottodirectory

Nella directory CSS, crea una sottodirectory chiamata dev e crea un file vuoto chiamato admin.scss e widget.scss poiché lavoreremo con questi file più avanti nella serie.

Quindi, aggiungi una directory dev alla directory JavaScript e aggiungi il file admin.js vuoto e i file widget.js a questi file. Se ti senti così incline, puoi spostare i file preesistenti nelle directory dev poiché questi sono i file che useremo come base per i nostri file di sviluppo.

Questo è un passaggio facoltativo; tuttavia, sono andato avanti e l’ho fatto perché è così che preferisco lavorare. Ecco l’insieme di comandi che ho eseguito.

Dalla directory css …

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Sopra, ho creato la directory dev per i miei fogli di stile, li ho rinominati in file Sass e li ho spostati nella directory dev.

Prima di andare avanti, ora è un buon momento per fare un controllo dello stato di git e confermare le modifiche relative ai fogli di stile:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Ora, dalla directory js …

$ mkdir dev
$ mv *.js dev

Dal momento che non dobbiamo modificare il tipo di file dei file associati, possiamo semplicemente spostarli nella nuova directory.

Infine, facciamo la stessa cosa e vediamo se ci sono modifiche che possiamo spingere attraverso un rapido controllo dello stato di git (che dovrebbe esserci). Ecco un elenco dei comandi che ho eseguito per eseguire il commit e il push delle mie modifiche:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Abbiamo quasi finito. Tutto ciò che resta da fare è spostare determinate directory nella radice del repository e rinominare la directory principale in src. Quindi facciamolo ora.

Sposta le directory nella radice

In sostanza, dobbiamo spostare tutto tranne il file del plug-in e la directory Views fuori dalla directory widget-boilerplate e dobbiamo rinominare widget-boilerplate in src.

Sembra semplice, vero? È piuttosto semplice. Dall’interno della directory widget-boilerplate :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Quindi eseguirò il commit della modifica su GitHub utilizzando quanto segue:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Ora abbiamo una struttura di directory molto più moderna impostata. Puoi vederlo qui nel mio ramo di sviluppo.

Una parola sull’OOP

E ora che abbiamo tutto questo a posto, possiamo iniziare a scrivere codice. Ma non fraintenderti: una parte della programmazione orientata agli oggetti è anche analisi orientata agli oggetti e progettazione orientata agli oggetti.

Quello che abbiamo fatto in questo post è essenzialmente applicare un progetto architettonico orientato agli oggetti basato sull’analisi di come il plugin si adatta insieme.

La parte successiva, tuttavia, sta aggiornando il codice per eliminare tutto il rosso che abbiamo visto annusando il nostro codice.

Nel prossimo post

L’obiettivo principale del prossimo post è continuare con l’aggiornamento degli standard di codifica in modo da aver risolto tutti i problemi generati dal nostro IDE o tramite gli strumenti di qualità del codice che stiamo eseguendo dalla riga di comando.

Dovremmo anche avere un repository molto più pulito e organizzato ed essere in una posizione in cui siamo pronti per unire il nostro lavoro al ramo principale.

Per ora, però, assicurati di avere una buona padronanza di tutto quanto sopra prima di procedere poiché è necessario capire per il resto del lavoro che abbiamo davanti a noi.