Semplicemente refactoring del codice basato su WordPress
Nel 2011, stavo leggendo molto sul lavoro con codice legacy, qualità del codice e refactoring.
C’è una citazione di Martin Fowler (che ha letteralmente scritto il libro sul refactoring) attribuita a zio Bob che è rimasta con me – e sono sicuro molti, molti programmatori – da allora:
lascia sempre il codice in uno stato migliore di quello che hai trovato
Il fatto di questa particolare idea è che penso che potrebbe suonare un po’ più idealistica finché non inizi davvero a provare a metterla in pratica in tutto ciò che fai.
Cioè, se lo prendi alla lettera sembra che ogni volta che devi lavorare su una base di codice, devi lasciare l’intera base di codice meglio di quando l’hai trovata. Ma più ho provato ad applicare questa regola nel mio lavoro quotidiano, più pratico, più pulito e più gestibile è diventato il codice specifico di WordPress.
Quindi, quando si tratta di refactoring del codice basato su WordPress, che aspetto ha?
Questo non sarà un post lungo. Invece, condividerò semplicemente alcuni punti elenco che seguo quando si tratta di lavorare su codice che ho scritto in precedenza, che incontro da altri o che proviene da una base di codice su cui ho lavorato con altri nel passato.
Senza un ordine particolare:
- Non essere idealista; Sii pratico. Il refactoring di un’intera base di codice non è pratica, soprattutto se la base di codice non è racchiusa in unit test. Guarda il codice su cui stai lavorando e vedi quali modifiche minori puoi fare per migliorarlo.
- Usa gli ultimi standard. Non è necessario configurare un ambiente di sviluppo completamente nuovo per il codice precedente. Invece, assicurati di avere buoni sniffer di codice in atto. Se sei passato da WordPress Coding Standards a PSR, guarda gli avvisi o gli avvisi che gli sniffer lanciano e tentano di aggiornare il codice solo in quel file (o insieme di file).
- Scrivi funzioni di supporto. Se le tue funzioni sono troppo lunghe, cerca dei modi per renderle più facili da usare. Innanzitutto, aggiorna tutte le strutture di controllo come loop o condizionali, quindi scrivi funzioni di supporto per renderle più facili da leggere.
- Aggiungi test (quando possibile). Se disponi già di un framework di unit test, aggiungi i test per il tuo nuovo codice. Se non hai il tempo o non hai la struttura, non preoccuparti. Per quanto lo predicono i programmatori pragmatici, non c’è sempre tempo per aggiungere test. (Questa non vuole essere un’affermazione che non sono utili o non dovrebbero essere inclusi, ma che non è sempre pratico incorporarli in un dato momento).
Alcune delle cose che mi sono ritrovato a fare negli ultimi progetti includono anche cose semplici:
- aggiornare i nomi di variabili e funzioni per seguire il PSR,
- cambiare le schede in spazi,
- aggiunta di funzioni di supporto per rendere più leggibili condizioni e cicli,
- suddividendo le classi in modo che abbiano un più alto grado di coesione,
- migliorare i docblock di ogni funzione
Questi sono solo alcuni degli esempi e questo chiaramente non è un elenco esaustivo. Ma non è questo il punto. Invece, sto cercando di condividere semplicemente come puoi applicare il refactoring del codice basato su WordPress per tutto il tempo mentre svolgi il tuo lavoro quotidiano in modo gestibile.
Tutte le modifiche o i consigli di cui sopra sono cose che di solito possono essere fatte con l’aiuto dell’IDE, alcune scorciatoie e forse con mezz’ora di tempo extra (e sono liberale con quella stima).
Quindi, no, non è necessario riscrivere un’intera base di codice. Non so nemmeno se questo sia un obiettivo pratico a cui puntare. Ma puoi aggiustare un piccolo pezzo del sistema generale di cui sei responsabile?
E perché non puntare almeno a questo?