Lezioni di Clean Code da Robert C. Martin per team più veloci

Perché Clean Code è ancora importante per i team moderni

Robert C. Martin — meglio noto come “Uncle Bob” — ha popolarizzato il movimento Clean Code con una premessa semplice: il codice dovrebbe essere scritto per la prossima persona che dovrà modificarlo (spesso quella persona sei tu fra tre settimane).

Manutenibilità e velocità del team (in parole semplici)

Manutenibilità è quanto facilmente il tuo team può capire il codice, modificarlo in sicurezza e rilasciare quei cambiamenti senza rompere parti non correlate. Se ogni piccola modifica sembra rischiosa, la manutenibilità è bassa.

Velocità del team è la capacità costante del team di consegnare miglioramenti utili nel tempo. Non è “digitare più veloce”: è quanto rapidamente puoi passare da un’idea a software funzionante, ripetutamente, senza accumulare danni che rallentano in seguito.

Perché la qualità del codice è una questione di team

Clean Code non riguarda i gusti stilistici di un singolo sviluppatore. È un ambiente di lavoro condiviso. Un modulo disordinato non frustra solo chi l’ha scritto; aumenta i tempi di revisione, rende l’onboarding più difficile, crea bug che richiedono più tempo per essere diagnosticati e costringe tutti a procedere con cautela.

Quando più persone contribuiscono alla stessa codebase, la chiarezza diventa uno strumento di coordinamento. L’obiettivo non è il “codice bello”, ma il cambiare prevedibile: chiunque nel team deve poter fare un aggiornamento, capire cosa tocca e sentirsi sicuro nel fare merge.

Abitudini pratiche, non perfezione

Clean Code può diventare eccessivo se trattato come un test di purezza. I team moderni hanno bisogno di linee guida che ripaghino nei veri deadline. Pensalo come un insieme di abitudini che riducono l’attrito—piccole scelte che si sommano in una consegna più veloce.

Nel resto dell’articolo ci concentreremo su tre aree che migliorano più direttamente la manutenibilità e la velocità:

• Nomi: rendere il significato evidente così le persone sprecano meno tempo a decodificare l’intento.
• Confini: separare responsabilità così le modifiche non creino effetti a catena.
• Disciplina: pratiche coerenti (review, test, refactor) che impediscono alla codebase di tornare nel caos.

L’idea centrale dietro Clean Code: ottimizzare per il cambiamento

Clean Code non riguarda principalmente l’estetica o le preferenze personali. Il suo obiettivo pratico è: rendere il codice facile da leggere, facile da comprendere e quindi facile da modificare.

I team raramente fanno fatica perché non sanno scrivere nuovo codice. Falliscono perché il codice esistente è difficile da modificare in sicurezza. I requisiti cambiano, emergono casi limite e le scadenze non si fermano mentre gli ingegneri “riscoprono” cosa fa il sistema.

Chiaro batte intelligente

Il codice “furbo” spesso ottimizza la soddisfazione momentanea dell’autore: logica condensata, scorciatoie inaspettate o astrazioni ardite che sembrano eleganti—finché qualcun altro non deve modificarle.

Il codice “chiaro” ottimizza per la prossima modifica. Favorisce flussi di controllo semplici, intenzioni esplicite e nomi che spiegano perché qualcosa esiste. L’obiettivo non è eliminare tutta la complessità (il software non può), ma collocarla dove serve e mantenerla visibile.

Il costo della confusione è misurabile

Quando il codice è difficile da capire, il team lo paga più volte:

• Consegna più lenta: più tempo speso a leggere, tracciare e ricontrollare.
• Più bug: fraintendimenti portano a fix errati o parziali.
• Più rifacimenti: gli ingegneri implementano soluzioni temporanee perché “toccare quell’area sembra rischioso”, accumulando debito tecnico.

Per questo Clean Code si collega direttamente alla velocità del team: ridurre la confusione riduce l’esitazione.

Principi, non comandamenti

Clean Code è un insieme di compromessi, non regole rigide. A volte una funzione leggermente più lunga è più chiara che spezzarla. A volte i vincoli di performance giustificano un approccio meno “bello”. Il principio resta: preferire scelte che mantengano le modifiche future sicure, locali e comprensibili—perché il cambiamento è lo stato predefinito del software reale.

Nomi: la via più rapida verso codice leggibile e manutenibile

Se vuoi codice facile da modificare, inizia dai nomi. Un buon nome riduce la quantità di “traduzione mentale” che il lettore deve fare—così può concentrarsi sul comportamento, non sul decifrare cosa significhi qualcosa.

Cosa dovrebbe comunicare un buon nome

Un nome utile porta informazioni:

• Intento: cosa rappresenta o fa la cosa (non come è implementata).
• Scopo: è un singolo valore, una collezione, una cache, una richiesta, una bozza?
• Unità e formato: Cents vs Dollars, Utc vs ora locale, Bytes vs Kb, stringa vs oggetto parsato.
• Vincoli: include tasse, è scontato, è validato, è un massimo?

Quando questi dettagli mancano, il lettore deve farsi delle domande—o peggio, indovinare.

Nomi ambigui vs chiari (esempi)

Nomi vaghi nascondono decisioni:

• data, info, tmp, value, result
• list, items, map (senza contesto)

Nomi chiari forniscono contesto e riducono i follow-up:

• invoiceTotalCents (unità + dominio)
• discountPercent (formato + significato)
• validatedEmailAddress (vincolo)
• customerIdsToDeactivate (scopo + intento)
• expiresAtUtc (fuso orario)

Anche piccole rinominazioni possono prevenire bug: timeout è vago; timeoutMs non lo è.

Coerenza: usa il linguaggio del prodotto

I team vanno più veloci quando il codice usa le stesse parole che si trovano nei ticket, nell’interfaccia utente e nelle conversazioni di supporto. Se il prodotto parla di “subscription”, evita di chiamarla plan in un modulo e membership in un altro, a meno che non siano concetti davvero diversi.

La coerenza significa anche scegliere un termine e mantenerlo: customer vs client, invoice vs bill, cancel vs deactivate. Se i termini sfuggono, il significato sfuma.

Il naming è coordinamento, non stile

Buoni nomi funzionano come piccoli pezzi di documentazione. Riducendo le domande su Slack (“Cosa contiene tmp?”) diminuiscono le iterazioni in review e si evitano fraintendimenti tra ingegneri, QA e product.

Checklist rapida per i nomi

Prima di committare un nome, chiediti:

• Un nuovo collega capirebbe cosa è questo senza aprire altri file?
• Indica unità/fuso/formato dove conta?
• È allineato alla terminologia del prodotto?
• Evita parole contenitorie come data a meno che il dominio non sia esplicito?
• Se è booleano, si legge chiaramente: isActive, hasAccess, shouldRetry?

Mantenere i nomi onesti: prevenire il “name drift” nel tempo

Un buon nome è una promessa: dice al prossimo lettore cosa fa il codice. Il problema è che il codice cambia più rapidamente dei nomi. Nel corso di mesi di patch rapide e “ship it”, una funzione chiamata validateUser() comincia a fare validazione e provisioning e analytics. Il nome appare ancora pulito, ma ora induce in errore—e i nomi ingannevoli costano tempo.

Perché i nomi devono riflettere ciò che il codice fa oggi

Clean Code non significa scegliere nomi perfetti una volta per tutte. Significa mantenere i nomi allineati alla realtà. Se un nome descrive ciò che il codice faceva, ogni futuro lettore dovrà dedurre la verità dall’implementazione. Questo aumenta il carico cognitivo, rallenta le review e rende più rischiose le piccole modifiche.

Come avviene il name drift nei team reali

Il name drift raramente è intenzionale. Di solito deriva da:

• Fix rapidi: patch sotto pressione senza rivedere l’intento
• Feature creep: “ancora una responsabilità” aggiunta a una funzione esistente perché è comodo
• Copia-incolla: clonare codice e modificare la logica mantenendo i nomi originali

Modi leggeri per mantenere i nomi accurati

Non servono comitati per i nomi. Alcune semplici abitudini bastano:

• Quando una funzione guadagna responsabilità, rinasinala o splittala così il vecchio nome rimane vero.
• Aggiungi una voce nella checklist di review: “I nomi descrivono ancora il comportamento?” (È veloce e cattura molti casi.)
• Se ti viene da scrivere un commento tipo “This actually…”, spesso è un segnale che serve rinominare.

La regola “rinomina mentre tocchi”

Durante qualsiasi piccola modifica—fix, refactor o tweak—dedica 30 secondi ad aggiornare il nome fuorviante più vicino. Questa abitudine impedisce che il drift si accumuli e mantiene la leggibilità in crescita con il lavoro quotidiano.

Confini: separare responsabilità per ridurre gli effetti a catena

Clean Code non riguarda solo metodi ordinati: riguarda tracciare confini chiari così le modifiche restano locali. I confini appaiono ovunque: moduli, livelli, servizi, API e persino “chi è responsabile di cosa” dentro una singola classe.

Separazione delle responsabilità (con un’analogia in cucina)

Pensa a una cucina con postazioni: preparazione, griglia, impiattamento e lavaggio. Ogni postazione ha un compito chiaro, strumenti e input/output. Se la griglia inizia a lavare i piatti “solo per questa volta”, tutto rallenta: mancano strumenti, si formano code e non è chiaro chi è responsabile quando qualcosa si rompe.

Il software funziona allo stesso modo. Con confini chiari, puoi modificare la “griglia” (logica di business) senza riorganizzare il “lavaggio piatti” (accesso ai dati) o l’“impiattamento” (formattazione UI/API).

Come i confini poco chiari rallentano i team

I confini confusi creano effetti a catena: una piccola modifica richiede edit in più aree, test extra, più giri di review e maggior rischio di bug non intenzionali. Il team comincia a esitare—ogni cambiamento sembra poter rompere qualcosa di non correlato.

Odori comuni di confine includono:

• Responsabilità miste: un modulo calcola prezzi e scrive sul database.
• Scorciatoie tra layer: codice UI che interroga direttamente il database “per performance”.
• Astrazioni che perdono dettagli: un servizio espone tabelle interne o oggetti ORM come API pubblica.
• Utility “helper” che accumulano comportamenti non correlati col tempo.

Come si percepiscono buoni confini nella pratica

Con buoni confini, i ticket diventano prevedibili. Una modifica a una regola di pricing tocca per lo più il componente di pricing, e i test ti dicono rapidamente se hai oltrepassato il limite. Le review diventano più semplici (“questo appartiene al livello di dominio, non al controller”) e il debug è più veloce perché ogni pezzo ha un solo posto dove guardare e una sola ragione per cambiare.

Funzioni piccole e intento chiaro: rendere il cambiamento più sicuro

Funzioni piccole e focalizzate rendono il codice più facile da modificare perché riducono la quantità di contesto da tenere in testa. Quando una funzione ha un unico compito chiaro, puoi testarla con pochi input, riusarla altrove e capire i fallimenti senza seguire un labirinto di passi non correlati.

“Fare una cosa” (con un esempio concreto)

Considera una funzione chiamata processOrder() che: valida un indirizzo, calcola tasse, applica sconti, addebita una carta, invia un’email e scrive log di audit. Non sta “processando un ordine”—sono cinque decisioni e tre effetti collaterali mescolati.

Un approccio più pulito separa gli intenti:

function processOrder(order) {
  validate(order)
  const priced = price(order)
  const receipt = charge(priced)
  sendConfirmation(receipt)
  return receipt
}

Ogni helper può essere testato e riutilizzato indipendentemente, e la funzione di alto livello si legge come una breve storia.

Perché le funzioni lunghe sono rischiose

Le funzioni lunghe nascondono punti di decisione e casi limite perché seppelliscono la logica condizionale in mezzo a lavoro non correlato. Un singolo if per “indirizzo internazionale” può influenzare tassazione, spedizione e testo dell’email—ma il collegamento è difficile da vedere quando è a 80 righe di distanza.

Passi pratici per il refactor

Comincia in piccolo:

• Extract function: evidenzia un blocco coerente e spostalo in calculateTax() o formatEmail().
• Rinomina: aggiorna i nomi in modo che descrivano gli esiti (applyDiscounts vs doDiscountStuff).
• Rimuovi duplicazione: se due rami ripetono gli stessi passi, estraili in un helper condiviso.

Guardrail (evita la frammentazione eccessiva)

Piccolo non significa “minuscolo a ogni costo”. Se crei molti wrapper di una riga o costringi il lettore a saltare cinque file per capire un’unica azione, hai scambiato chiarezza con indirezione. Mira a funzioni corte, significative e comprensibili localmente.

Gestire gli effetti collaterali: meno sorprese, debug più semplice

Un effetto collaterale è qualsiasi cambiamento che una funzione fa oltre a restituire il suo valore. In termini semplici: chiami un helper aspettandoti una risposta e questo silenziosamente cambia qualcosa—scrive su file, aggiorna una riga di DB, muta un oggetto condiviso o cambia una flag globale.

Gli effetti collaterali non sono automaticamente “cattivi”. Il problema sono gli effetti nascosti. Questi sorprendono i chiamanti e le sorprese sono ciò che trasforma un cambiamento semplice in lunghe sessioni di debug.

Perché gli effetti collaterali rallentano i team

I cambiamenti nascosti rendono il comportamento imprevedibile. Un bug può apparire in una parte dell’app ma essere causato da un helper “comodo” altrove. Questa incertezza uccide la velocità: gli ingegneri spendono tempo a riprodurre il problema, aggiungere logging temporaneo e discutere su dove debba stare la responsabilità.

Rendono anche i test più difficili: una funzione che scrive sul DB o tocca lo stato globale ha bisogno di setup/cleanup, e i test cominciano a fallire per motivi non collegati alla feature in sviluppo.

Pattern che riducono le sorprese

Preferisci funzioni con input e output chiari. Se qualcosa deve modificare il mondo esterno, fallo in modo esplicito:

• Passa le dipendenze (logger, repository, clock) invece di prendere globali.
• Separa “calcola” da “fai”: una funzione calcola; un’altra esegue la scrittura.
• Nomina gli effetti onestamente (es. saveUser() vs getUser()).

Gotcha comuni includono logging dentro helper di basso livello, mutazioni di oggetti di configurazione condivisi e scritture su DB durante quello che sembra un passo di formattazione o validazione.

Checklist rapida per le review

Quando revisioni il codice, fai una semplice domanda: “Cosa cambia oltre al valore restituito?”

Follow-up: muta argomenti? Tocca stato globale? Scrive su disco/rete? Attiva job in background? Se sì, possiamo rendere quell’effetto esplicito o spostarlo a un confine migliore?

Disciplina: l’effetto composto sulla velocità di consegna

Clean Code non è solo una preferenza stilistica—è disciplina: abitudini ripetute che mantengono la codebase prevedibile. Pensalo meno come “scrivere codice carino” e più come routine che riducono la varianza: test prima di cambi rischiosi, piccoli refactor quando tocchi il codice, documentazione leggera dove impedisce confusione e review che catturano problemi presto.

Velocità ora vs velocità nel prossimo mese

I team possono spesso “andare veloci” oggi saltando queste pratiche. Ma quella velocità è solitamente presa in prestito dal futuro. Il conto arriva con release instabili, regressioni inaspettate e caos di fine ciclo quando una modifica semplice scatena una reazione a catena.

La disciplina scambia un piccolo costo costante per affidabilità: meno emergenze, meno fix dell’ultimo minuto e meno situazioni in cui il team deve fermarsi per stabilizzare una release. Nel corso di un mese, quella affidabilità diventa vera produttività.

Pratiche quotidiane che si compongono

Alcuni comportamenti semplici sommano velocemente:

• Aggiungi o aggiorna un test quando risolvi un bug (così resta risolto).
• Refatta l’area che hai toccato mentre è ancora fresca in testa (rinomina, estrai funzione, rimuovi duplicazione).
• Mantieni le modifiche piccole e facili da revisionare (branch brevi, descrizioni PR chiare).
• Considera la code review come proprietà condivisa: chiediti “la prossima persona capirà questo?” non solo “funziona?”

“Non abbiamo tempo per la pulizia”

Questa obiezione è spesso vera nel momento—e costosa nel tempo. La compromesso pratico è la portata: non pianificare una pulizia massiccia; applica disciplina ai margini del lavoro quotidiano. Nel tempo, quei piccoli depositi riducono il debito tecnico e aumentano la velocità di consegna senza un grande rewrite.

I test come guardiani dei confini e rete di sicurezza per il refactor

I test non servono solo a “catturare bug”. In termini Clean Code, proteggono i confini: il comportamento pubblico che il tuo codice promette alle altre parti del sistema. Quando cambi l’interno—dividi un modulo, rinasini metodi, sposti logica—i buoni test confermano che non hai rotto il contratto.

Feedback rapido batte correzioni tardive

Un test fallito pochi secondi dopo una modifica è economico da diagnosticare: ricordi ancora cosa hai toccato. Paragonalo a un bug trovato giorni dopo in QA o produzione, quando la pista è fredda, la correzione è più rischiosa e più cambiamenti sono intrecciati. Il feedback rapido trasforma il refactor da scommessa a routine.

Cosa testare prima (quando il tempo è limitato)

Inizia con copertura che ti dà libertà:

• Comportamento critico: flussi che fanno soldi, proteggono dati o bloccano utenti.
• Logica difficile: casi limite, parsing, fusi orari, arrotondamenti, permessi.
• Fallimenti comuni: input noti problematici, integrazioni instabili, regole di retry.

Una euristica pratica: se un bug sarebbe costoso o imbarazzante, scrivi un test che lo avrebbe intercettato.

Mantieni i test leggibili—come documentazione

I test puliti accelerano il cambiamento. Trattali come esempi eseguibili:

• Nomina i test con intento: rejects_expired_token() si legge come un requisito.
• Preferisci setup chiaro a helper troppo astuti. Se un helper nasconde significato, non aiuta.
• Asserisci risultati, non passi interni. Vuoi libertà di riscrivere l’implementazione.

Evita test fragili che rallentano il cambiamento

I test diventano un peso quando ti vincolano alla struttura di oggi—over-mocking, asserire dettagli privati o dipendere da testo/HTML esatti dell’UI quando ti interessa solo il comportamento. I test fragili falliscono per “rumore”, insegnando al team a ignorare build rosse. Mira a test che falliscano solo quando qualcosa di significativo si rompe.

Abitudini di refactor: piccoli passi che mantengono il debito sotto controllo

Il refactor è una delle lezioni più pratiche di Clean Code: è un miglioramento che preserva il comportamento della struttura del codice. Non cambi cosa fa il software; cambi quanto sia chiaro e sicuro da modificare la prossima volta. Una mentalità semplice è la Regola dei Boy Scout: lascia il codice un po’ più pulito di come lo hai trovato. Non significa lucidare tutto. Significa fare piccoli miglioramenti che rimuovono attrito per la prossima persona (spesso il te futuro).

Refactor sicuri e piccoli che ripagano in fretta

I migliori refactor sono a basso rischio e facili da revisionare. Alcuni che riducono costantemente il debito tecnico:

• Rinomina variabili, funzioni e classi per allinearle a ciò che fanno davvero (soprattutto dopo che i requisiti sono cambiati).
• Extract method quando un blocco ha uno scopo singolo ma è sepolto in una funzione lunga.
• Semplifica condizionali rimuovendo negazioni, unificando rami duplicati o introducendo helper ben nominati.

Queste modifiche sono piccole, ma rendono l’intento ovvio—accorciando debug e velocizzando modifiche future.

Quando refactorare (senza bloccare la consegna)

Il refactor funziona meglio quando è legato a lavoro reale:

• Prima di aggiungere una feature: libera il percorso così il nuovo codice si inserisce naturalmente, invece di forzare hack.
• Dopo aver fixato un bug: una volta trovato il punto debole, rendi più difficile il ritorno della stessa classe di bug.

Quando fermarsi

Il refactor non è una scusa per un “cleanup” infinito. Fermati quando lo sforzo diventa una riscrittura senza un obiettivo chiaro e testabile. Se il cambiamento non può essere espresso come una serie di piccoli passi revisionabili (ognuno sicuro da fare merge), dividilo in milestone più piccole—o non farlo al momento.

Code review e standard: trasformare i principi in abitudini di team

Clean Code migliora la velocità solo quando diventa un riflesso del team—non una preferenza personale. Le code review sono il luogo in cui principi come nomi, confini e funzioni piccole diventano aspettative condivise.

A cosa serve una review

Una buona review ottimizza per:

• Comprensione condivisa: più di un “LGTM”—il team dovrebbe capire cosa è cambiato e perché.
• Coerenza: nomi, struttura e convenzioni che rendono il codice familiare in tutta la codebase.
• Controllo dei confini: le responsabilità sono separate o abbiamo nascosto logica tra i layer?
• Gestione del rischio: identificare effetti collaterali, casi limite e preoccupazioni di rollout in anticipo.

Un template leggero per le review

Usa una checklist ripetibile per velocizzare le approvazioni e ridurre andirivieni:

1. Intento: quale problema risolve questa modifica? Il design è semplice?
2. Leggibilità: i nomi sono specifici e onesti? C’è codice “clever” che potrebbe essere più chiaro?
3. Confini: abbiamo mantenuto responsabilità nel posto giusto (UI/service/domain/data)?
4. Test: cosa dimostra che funziona? Cosa fallirebbe se questo si rompesse?
5. Rischi: performance, sicurezza, migrazioni, retrocompatibilità.
6. Follow-up: quale debito abbiamo intenzionalmente posticipato (con ticket)?

Standard che riducono il dibattito

Standard scritti (convenzioni di naming, struttura delle cartelle, pattern di gestione errori) rimuovono argomentazioni soggettive. Invece di “Preferisco…”, i reviewer possono indicare “Lo facciamo così”, accelerando le revisioni e riducendo la personalità nelle discussioni.

Gentilezza e chiarezza

Critica il codice, non lo sviluppatore. Preferisci domande e osservazioni piuttosto che giudizi:

• “Potremmo rinominare process() in calculateInvoiceTotals() per riflettere cosa restituisce?”
• “Questa funzione attraversa il confine di persistenza—non dovrebbe farlo il repository?”

Commenti: utili vs rumorosi

Buon commento:

// Perché: l’arrotondamento deve corrispondere alle regole del payment provider (vedi PAY-142).

Commento rumoroso:

// increment i

Punta a commenti che spiegano perché, non cosa il codice già dice.

Come applicare Clean Code per migliorare la velocità (senza dogmi)

Clean Code aiuta solo se rende più facile cambiare. Il modo pratico per adottarlo è trattarlo come un esperimento: concorda poche pratiche, misura i risultati e mantieni ciò che riduce realmente l’attrito.

Questo è ancora più importante quando i team si affidano sempre più a strumenti di sviluppo assistito dall’AI. Che tu generi scaffolding con un LLM o iteri dentro workflow tipo Koder.ai, gli stessi principi valgono: nomi chiari, confini espliciti e refactor disciplinati sono ciò che impedisce che l’iterazione veloce si trasformi in spaghetti difficili da modificare. Gli strumenti accelerano la produzione, ma le abitudini di Clean Code preservano il controllo.

Misura la velocità misurando l’attrito

Invece di discutere di stile, osserva segnali che correlano con i rallentamenti:

• Tempo ciclo PR: tempo dall’apertura di una PR al merge (e tempo in “in attesa di review”).
• Tasso di difetti: bug trovati in QA/produzione per release.
• Tempo di onboarding: quanto tempo prima che un nuovo collega rilasci una modifica sicura.
• Rifacimenti: percentuale di lavoro che viene annullata (rollback, ticket riaperti, “fix del fix”).

Tieni traccia del dolore con un semplice “log di attrito”

Una volta a settimana, spendi 10 minuti a catturare problemi ripetuti in una nota condivisa:

• “Difficile trovare dove X è implementato.”
• “I test si rompono per cambi non correlati.”
• “Questo modulo ha troppi motivi per cambiare.”

Col tempo emergono pattern. Questi pattern dicono quale abitudine di Clean Code pagherà di più dopo.

Crea un piccolo accordo di team

Mantienilo semplice e applicabile:

• Regole di naming: preferire nomi che rivelano l’intento; bandire parole vaghe come data, manager, process a meno che non siano scoping espliciti.
• Regole di confine: un modulo = una responsabilità chiara; evitare di mescolare persistenza, regole di business e formattazione nello stesso unit.
• Minimi di testing: ogni bug fix aggiunge un test; nuovo comportamento viene rilasciato con un test al livello appropriato.

Piano di rollout in 30 giorni (una abitudine a settimana)

• Settimana 1 — Naming: rinomina i peggiori offender che tocchi; richiedi “il nome corrisponde ancora?” nelle PR.
• Settimana 2 — Confini: estrai una seam di dipendenza (es. incapsula un’API esterna dietro un’interfaccia).
• Settimana 3 — Effetti collaterali: rendi un flusso più prevedibile (ritorna valori invece di mutazioni nascoste; logging ai bordi).
• Settimana 4 — Refactor con test: scegli un file hotspot e miglioralo con PR piccoli.

Rivedi le metriche a fine settimana e decidete cosa mantenere.

Checklist rapida

• Un nuovo arrivato trova la posizione della modifica in meno di 2 minuti?
• I nomi corrispondono ancora al comportamento dopo l’ultima modifica?
• C’è un confine chiaro tra logica di business e IO?
• È possibile cambiare una parte senza toccarne cinque altre?
• Questa PR riduce il lavoro futuro (o lo aumenta)?