Clean Code: guida utile (non dogma)

Clean Code di Robert C. Martin è uno dei libri più influenti degli ultimi vent’anni nello sviluppo software. Ha aiutato moltissimi team a scrivere codice più leggibile e manutenibile.

Ho visto anche l’effetto collaterale: team che applicano regole “da libro” senza contesto e finiscono per produrre complessità non necessaria. Codice elegante, sì, ma costoso: più file, più livelli, più cerimonia. E tempi di consegna che si allungano.

Il problema non è Clean Code. Il problema è trattarlo come dogma invece che come bussola. E quella differenza, nel software, si paga in soldi, tempo e opportunità.

Cosa Clean Code fa bene (molto bene)

Prima di criticare, vale la pena riconoscere cosa funziona davvero. I nomi che significano qualcosa sono una forma di manutenzione preventiva: calculateMonthlyRevenue() è molto meglio di calc(), perché riduce il tempo di comprensione, accelera l’onboarding e limita gli errori banali. Lo stesso vale per funzioni piccole e con responsabilità chiara. Non serve l’ossessione delle “5 righe massimo”, ma una funzione leggibile è più facile da testare, modificare e correggere di un blocco enorme che mescola logica, side effect e condizioni.

Conta molto anche la struttura prevedibile. Convenzioni condivise su stile, organizzazione ed error handling rendono il codice più navigabile e riducono la frizione: meno tempo perso a interpretare scelte arbitrarie.

Se un team parte dal caos, Clean Code spesso è un upgrade immediato. Il guaio inizia quando “linee guida” diventano “legge”.

Dove il dogma fa danni

Il danno tipico è sempre lo stesso: ottimizzi la forma del codice prima di sapere se quella forma serve. Vale anche per principi come SOLID, cioè un insieme di regole usate per rendere il codice più ordinato e meno rigido, che diventano utili solo se applicati con giudizio.

Astrarre troppo presto

Ridurre duplicazione è utile, ma la duplicazione “piccola” a volte è un compromesso accettabile. Il rischio vero non è ripetere tre righe: è creare un’astrazione sbagliata che vincola tutto il progetto.

Una regola pratica: duplica finché non vedi un pattern stabile. Se il comportamento si sta ancora chiarendo (tipico di prodotti giovani), astrarre subito è come cementare una decisione quando non hai ancora capito la strada.

Un po’ di duplicazione costa poco. Un’astrazione prematura costa settimane quando scopri che era quella sbagliata.

Frammentare il codice in troppi micro-file

“Classi piccole” è un buon principio finché migliora la comprensione. Oltre una certa soglia diventa frammentazione: per seguire un flusso devi saltare tra 10 file, e la leggibilità peggiora.

Segnale tipico: “Per capire il login devo aprire 12 classi”. In quel caso hai solo spostato la complessità: da dentro un file a tra file.

A volte una classe di 150 righe ben organizzata è più leggibile di 8 classi da 20 righe che si rimbalzano responsabilità.

Test come cerimonia

L’enfasi sui test è positiva. Ma se diventa “testiamo tutto perché sì”, ottieni una suite enorme che non protegge i flussi critici. È facile finire a testare getter/setter e logica ovvia, mentre restano scoperti i punti dove il business perde davvero soldi (pagamenti, permessi, integrazioni). È lo stesso problema della coverage: puoi avere numeri alti e non testare ciò che conta.

La domanda giusta non è “quanta coverage?”. È: “che incidente stiamo prevenendo con questo test?”

SOLID applicato senza contesto

SOLID è utile su sistemi complessi. Applicato ovunque e subito, può trasformare un progetto semplice in un labirinto di interfacce e livelli.

Regola pratica: usa SOLID per ridurre rischio e accoppiamento nei punti caldi (moduli core, logica instabile, aree con molte modifiche). Non trasformarlo in un requisito estetico su ogni form e ogni endpoint.

Per un MVP, spesso la priorità è avere un sistema chiaro, modificabile e consegnato in tempo — più che inseguire l’architettura “da manuale”.

Il costo concreto del dogma

Per chi gestisce un prodotto, questi eccessi si traducono in effetti misurabili. I tempi di consegna si gonfiano perché la “forma perfetta” diventa parte implicita del requisito, anche quando nessuno l’aveva chiesta. L’onboarding rallenta, perché più livelli e più frammentazione rendono difficile capire dove mettere mano, soprattutto quando le astrazioni non rispondono a un bisogno reale.

Poi c’è il refactoring infinito. Se il team viene premiato più per “pulire” che per consegnare, entra in un ciclo di perfezionamento continuo: il codice migliora marginalmente, mentre il prodotto rallenta. E naturalmente diventano più instabili anche le stime, perché stai stimando la feature insieme a tutta la cerimonia che le viene costruita attorno.

Dov’è il confine: 5 regole pratiche

Il confine pratico si può riassumere così. I nomi chiari vanno quasi sempre scelti, perché hanno un ritorno altissimo e costano poco. Le astrazioni hanno senso quando esistono insieme ripetizione e stabilità; se la logica cambia spesso, conviene aspettare. La leggibilità del flusso conta più della frammentazione elegante: se per capire una feature devi aprire troppi file, hai già perso qualcosa.

Anche i test vanno scelti per impatto, non per rituale. Ha senso proteggere i flussi che costano soldi quando si rompono, come pagamenti, permessi, integrazioni e regressioni. E soprattutto la qualità va misurata nel tempo, non nel gusto personale. La domanda utile è sempre la stessa: quanto ci costerà cambiare questa cosa tra tre mesi?

La sensibilità conta più delle regole

Clean Code ti dà un vocabolario e una direzione. Ma la parte che fa la differenza è il giudizio: sapere quando un principio va applicato e quando diventa overhead.

Il codice deve servire il business, non vincere un concorso di eleganza. Una cattedrale è impressionante, ma se dovevi costruire una casa abitabile in quattro settimane, hai sbagliato obiettivo. La semplicità è la cosa più difficile da ottenere, e spesso è il segno di vera competenza.

Come riconoscere il problema

Alcuni segnali sono chiari: feature piccole che diventano “progetti architetturali”, un team che parla spesso di “rifare bene” ma consegna poco, codice apparentemente pulitissimo insieme a onboarding lento, modifiche che richiedono di toccare troppi livelli e troppe classi. In questi casi stai comprando complessità spacciata per qualità.