Sviluppare software può sembrare una performance pubblica. Internet premia i lanci, gli screenshot e i punti elenco del changelog. Così, quando uno sviluppatore trascorre un'intera sessione su un progetto senza avere nulla di visibile da mostrare, l'istinto è quello di considerare quella giornata come sprecata. L'ultimo dev log della Food Blog Platform dimostra il contrario. Non c'erano nuove ricette da visualizzare, né schede ridisegnate, né pulsanti aggiuntivi su cui gli utenti potessero cliccare. Solo codice che è stato smontato, esaminato e rimontato meglio di prima.
Questo è il lavoro invisibile che mantiene in vita i progetti a lungo termine.
Le funzionalità si prendono la gloria; il refactoring mantiene le luci accese
Quando si gestisce una piattaforma di food blog, la superficie appare semplice. Gli utenti pubblicano ricette, caricano foto e navigano per categoria. Sotto la superficie, però, si stanno gestendo pipeline di immagini, relazioni nel database tra ingredienti e istruzioni, indici di ricerca e livelli di caching. Con il tempo, le soluzioni rapide si accumulano. Una funzione helper copiata in tre file diversi. Una query al database che aveva senso per dieci post, ma che diventa lentissima quando ne raggiunge mille. CSS che era iniziato in modo organizzato, finché cinque patch d'emergenza non lo hanno trasformato in un labirinto.
Il refactoring significa affrontare direttamente questo disordine. Può significare consolidare la logica duplicata in modo che un modulo di modifica della ricetta e una dashboard amministrativa attingano dallo stesso livello di validazione invece di mantenere versioni parallele. Può significare semplificare il modo in cui le immagini vengono elaborate, in modo che la routine di compressione venga eseguita una sola volta invece che ogni volta che una pagina viene ricaricata. O potrebbe comportare la ristrutturazione del codebase in modo che l'aggiunta di un nuovo tipo di contenuto in futuro non richieda di setacciare sei directory non correlate.
Nulla di tutto ciò appare nell'interfaccia utente. Un visitatore che atterra sul sito non vedrà un banner con scritto "query ottimizzata" o "componente disaccoppiato". Ma lo percepirà quando il sito caricherà più velocemente. Noterà quando una nuova funzionalità apparirà tre giorni dopo la richiesta invece di tre settimane. Lo sviluppatore non ha aggiunto capacità oggi. Ha spianato la strada affinché nuove capacità possano essere aggiunte senza dover combattere contro il codebase.
Il codice pulito è un investimento contro i fallimenti futuri
Ogni progetto che dura più di un mese accumula attrito. Costruisci un prototipo rapido per testare un'idea. Poi arrivano gli utenti. Poi hai bisogno di un livello di autenticazione, poi di una coda di moderazione e poi di un layout mobile. Ciascuna di queste aggiunte viene agganciata a qualsiasi struttura già esistente. Senza una manutenzione regolare, l'architettura inizia a somigliare a una casa in cui ogni nuova stanza è stata progettata da una persona diversa che non ha mai visto la planimetria.
Il debito tecnico non è un fallimento della disciplina. È un sottoprodotto naturale del dover scendere a compromessi per rilasciare qualcosa di concreto. Il pericolo non è che il tuo codice sia imperfetto. Il pericolo è lasciarlo imperfetto così a lungo che cambiare una singola variabile rompa tre funzionalità non correlate. Ti ritrovi ad aver paura di toccare la barra di ricerca perché l'ultima volta che ci hai provato, il sistema dei tag si è rotto. Rimandi l'aggiunta di un widget per la pianificazione dei pasti perché sai che lo schema del database è diventato un nodo che richiederà ore per essere sciolto.
Trascorrere una giornata a fare refactoring è come estinguere quel debito prima che gli interessi ti sommergano. Impedisce ai piccoli problemi di cristallizzarsi in problemi grandi. Quando la Food Blog Platform aggiungerà infine la sua prossima funzionalità importante, lo sviluppatore non dovrà danzare intorno a un codice fragile. Scriverà la nuova logica, la collegherà a un'interfaccia pulita e andrà avanti. Questo è il ritorno sull'investimento.
Piccoli passi, vero apprendimento
Esiste una sorta di mitologia attorno allo sviluppo software che dice che il progresso consista in intuizioni geniali e sessioni di coding marathon che riscrivono tutto dalla sera alla mattina. La maggior parte degli sviluppatori professionisti ti dirà che è una fantasia. Il vero progresso somiglia alla diff di un martedì pomeriggio in cui tre funzioni sono diventate più brevi, una dipendenza ridondante è stata rimossa e il nome di una variabile confusionaria è stato cambiato affinché il prossimo lettore capisca effettivamente cosa faccia.
Il dev log della Food Blog Platform cattura perfettamente questo ritmo. Sviluppare software significa apportare piccoli miglioramenti costanti. Si impara da ogni sfida. Forse oggi la sfida è stata capire perché un particolare modulo fosse diventato così dipendente da un altro. Forse è stato rendersi conto che una scorciatoia presa due settimane fa aveva già iniziato a costare più tempo di quanto ne avesse fatto risparmiare. Ogni commit rende il progetto migliore, anche quando quel commit elimina più di quanto crei.
Questo approccio protegge anche la tua motivazione. Le riscritture massicce sono estenuanti e rischiose. Introducono nuovi bug mentre ne risolvono di vecchi. Refactoring incrementale, fatto.