Principi di Programmazione: Guida per Scrivere Codice Manutenibile

Nel panorama tecnologico attuale, i framework evolvono e tramontano con una rapidità disarmante, ma i principi fondamentali della programmazione restano punti fermi immutabili. Questa guida esplora le regole d'oro che trasformano un semplice sviluppatore in un professionista della manutenibilità, offrendo una bussola pratica per navigare tra codice legacy e nuovi progetti.

La gerarchia dell'ottimizzazione: Funzionante, Corretto, Veloce

Questo principio, coniato da Kent Beck (padre dell'Extreme Programming), stabilisce un ordine di priorità rigoroso per evitare l'over-engineering, ovvero la tendenza a progettare soluzioni più complesse del necessario.

1. Make it work (Fallo funzionare): Il primo obiettivo è risolvere il problema. In questa fase non bisogna preoccuparsi della pulizia del codice o delle performance, ma solo di ottenere una soluzione funzionante.

2. Make it right (Fallo bene): Una volta che il codice funziona, si procede al refactoring — la ristrutturazione del codice per migliorarne la leggibilità e la struttura senza cambiarne il comportamento. Qui si inseriscono test, nomi di variabili chiari e architetture pulite.

3. Make it fast (Fallo veloce): Solo se necessario, si ottimizzano le prestazioni. Spesso i colli di bottiglia che temiamo non si presentano mai nella realtà.

YAGNI: Non anticipare bisogni futuri

L'acronimo YAGNI sta per "You Aren't Gonna Need It" (Non ne avrai bisogno). È un monito contro la costruzione di funzionalità basate su ipotesi future che raramente si avverano.

Un esempio tipico è lo sviluppatore che, dovendo esportare dati in formato CSV, decide di creare un sistema generico che supporti anche JSON, XML e PDF "per sicurezza". Dopo sei mesi, l'unica funzione utilizzata resta il CSV, ma lo sviluppatore deve continuare a manutenere e correggere bug in tre moduli inutilizzati. Costruisci per le esigenze di oggi; domani avrai informazioni migliori per decidere.

Il Principio della Minima Sorpresa

Il codice migliore è quello "noioso". Quando un collega apre un tuo file, non dovrebbe mai esclamare "Cosa succede qui?". La sorpresa è il terreno fertile dove proliferano i bug.

Consideriamo una funzione chiamata getUser(). Se, oltre a restituire l'utente, aggiorna silenziosamente il timestamp dell'ultimo accesso nel database, sta violando questo principio. Il nome promette una lettura (read), ma il corpo esegue una scrittura (write). La prevedibilità vince sempre sull'ingegno: una funzione deve fare esattamente ciò che dice il suo nome, niente di più.

KISS: Semplicità come valore assoluto

KISS (Keep It Simple, Stupid) suggerisce che la soluzione più semplice è quasi sempre la migliore. La complessità è facile da aggiungere ma estremamente difficile da rimuovere.

Invece di creare funzioni giganti da 200 righe che gestiscono ogni caso possibile tramite parametri booleani (es. processData(data, true, false, true)), è preferibile dividere la logica in tre funzioni piccole e ben nominate. Prima di creare un'astrazione elegante, chiediti se serve davvero o se stai solo cercando di mostrare la tua bravura tecnica.

DRY e il rischio dell'astrazione prematura

DRY (Don't Repeat Yourself) afferma che ogni pezzo di conoscenza deve avere una singola rappresentazione autoritativa all'interno del sistema. Se la logica di validazione di una password è copiata in tre punti diversi, modificarla richiederà tre interventi, aumentando il rischio di dimenticanze.

SOLID: I cinque pilastri della manutenibilità

SOLID è un acronimo che racchiude cinque principi della programmazione a oggetti (OOP) volti a rendere il software più flessibile e facile da modificare:

• S - Single Responsibility: Una classe deve avere un solo motivo per cambiare. Non mescolare gestione email e formattazione fatture nello stesso oggetto.

• O - Open/Closed: Il codice deve essere aperto alle estensioni ma chiuso alle modifiche. Aggiungere un nuovo metodo di pagamento non dovrebbe costringerti a modificare un gigantesco blocco if/else esistente.

• L - Liskov Substitution: Una sottoclasse deve poter sostituire la sua classe base senza rompere il sistema.

• I - Interface Segregation: Meglio molte interfacce specifiche che una sola "generica" che obbliga a implementare metodi inutilizzati.

• D - Dependency Inversion: Dipendi dalle astrazioni, non dai dettagli concreti. La logica di business non dovrebbe sapere quale database specifico stai usando.

Piccoli passi e il Metodo Mikado

I grandi cambiamenti sono rischiosi perché falliscono in modi imprevedibili. Lavorare per Baby Steps (piccoli passi) significa scrivere poche righe, testare, fare un commit e ripetere. Se qualcosa si rompe, l'errore è necessariamente nell'ultima minima modifica.

Per i refactoring complessi che sembrano far crollare l'intero progetto, si applica il Metodo Mikado:

Conclusione: Trovare l'equilibrio tra i principi

La vera sfida professionale emerge quando i principi entrano in conflitto. YAGNI ti suggerisce di non costruire, mentre SOLID ti spinge a creare astrazioni. DRY ti dice di unificare, mentre il Principio della Minima Sorpresa ti suggerisce di mantenere la chiarezza anche a costo di ripeterti.

Il segreto risiede nel trattarli come una gerarchia: i principi fondamentali (farlo funzionare, YAGNI, semplicità) vengono prima di quelli architetturali. Quando due regole si scontrano, quella più vicina alla base della piramide — l'utilità immediata e la semplicità — deve prevalere.