Clean Code è un'ottima guida. Non è la Bibbia

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.

Nomi che significano qualcosa. calculateMonthlyRevenue() è meglio di calc(). Non è estetica: è manutenzione. Un codice con nomi chiari riduce il tempo di comprensione, accelera l’onboarding e riduce errori banali. Per il business significa che il team cambia meno velocità quando entrano persone nuove.

Funzioni piccole e con responsabilità chiara. Non serve ossessione per “5 righe massimo”, ma una funzione che fa una cosa leggibile è più facile da testare, modificare e correggere. Una funzione enorme, che mescola logica, side effect e condizioni, diventa un punto dove nessuno vuole mettere mano.

Struttura prevedibile. Convenzioni condivise (stile, organizzazione, error handling) rendono il codice più navigabile. Il valore non è “essere perfetti”, è ridurre 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.

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 non hai creato chiarezza: hai 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à non è avere l’architettura “da manuale”, ma avere un sistema chiaro, modificabile e consegnato in tempo.

Il costo concreto del dogma

Per chi gestisce un prodotto, questi eccessi si traducono in effetti misurabili.

Tempi di consegna gonfiati. Feature semplici richiedono più tempo perché la “forma perfetta” diventa parte del requisito. Non è qualità: è scope nascosto.

Onboarding più lento. Più livelli e più frammentazione spesso aumentano il tempo necessario a capire “dove si mette mano”, soprattutto se le astrazioni non sono motivate da un bisogno reale.

Refactoring infinito. Se il team è incentivato a “pulire” più che a consegnare, si entra in un ciclo di perfezionamento continuo. Il codice migliora marginalmente, ma l’output di prodotto rallenta.

Stime più instabili. Quando “fatto bene” significa “aggiungiamo strati”, le stime diventano ancora più difficili: non stai stimando solo la feature, stai stimando anche la cerimonia.

Dov’è il confine: 5 regole pratiche

1. Nomi chiari sempre. È il miglior ROI: costa poco, rende tutto più veloce.
2. Astrazioni solo quando c’è ripetizione + stabilità. Se la logica sta cambiando spesso, aspetta.
3. Ottimizza per leggere il flusso. Se per capire una feature devi aprire troppi file, hai frammentato.
4. Testa i flussi che costano soldi quando si rompono. Pagamenti, permessi, integrazioni, regressioni.
5. La qualità si misura nel tempo, non nel gusto. La domanda è: “quanto ci costa cambiare questa cosa tra 3 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.

Per il CEO: come riconoscere il problema

Alcuni segnali sono chiari:

• Feature piccole diventano “progetti architetturali”.
• Il team parla spesso di “rifare bene” ma consegna poco.
• Il codice è “pulitissimo”, ma l’onboarding è lento.
• Ogni modifica richiede toccare molti livelli e molte classi.

In questi casi, non stai comprando qualità: stai comprando complessità.