Scegliere cosa refactorare e cosa lasciare fermo

Questa lezione appartiene al Modulo 22 — Refactoring avanzato e varianti.

Il problema della scelta

Dopo aver imparato le tecniche di refactoring, il passo successivo è capire quando applicarle. Non tutto il codice “brutto” merita di essere refactorizzato. Non tutto il codice “pulito” deve restare intoccato.

Refactorare senza criterio spreca tempo e introduce rischi. Lasciare fermo tutto non migliora il progetto.

Il criterio principale: il costo del cambiamento futuro

La domanda giusta non è “questo codice è bello?” ma “quanto costano le modifiche future se lascio questo codice com’è?”.

Un pezzo di codice che:

• non viene mai toccato → costo futuro basso → lascia fermo
• viene toccato raramente → costo futuro basso → lascia fermo
• viene toccato spesso → costo futuro alto → considera il refactoring
• è difficile da capire → aumenta il costo di ogni modifica → valuta il refactoring
• rende impossibile testare → ogni modifica è rischiosa → refactoring prioritario

La matrice di priorità

Usa questa matrice per classificare ogni parte del progetto:

                    TOCCO SPESSO    TOCCO RARAMENTE
                   ┌─────────────────────────────────┐
DIFFICILE          │  REFACTORING   │   VALUTA        │
DA CAPIRE          │  PRIORITARIO   │   (basso ROI)   │
                   ├─────────────────────────────────┤
FACILE             │  REFACTORING   │   LASCIA        │
DA CAPIRE          │  SE BLOCCA     │   FERMO         │
                   └─────────────────────────────────┘

Quadrante “Refactoring prioritario”: difficile da capire, tocco spesso. Ogni modifica richiede di capire codice complesso — il rischio di introdurre bug è alto.

Quadrante “Lascia fermo”: facile da capire, tocco raramente. Funziona. Non costare nulla di toccarlo. Non spendere tempo qui.

Quadrante “Valuta (basso ROI)”: difficile da capire, tocco raramente. Il refactoring migliora la leggibilità, ma se non ci torni mai, il beneficio è minimo.

Quadrante “Refactoring se blocca”: facile da capire, tocco spesso. Funziona e lo capisci — ma se aggiungere funzionalità è difficile, potrebbe valere un refactoring mirato.

Applicazione al Registro del laboratorio

Classifica ogni componente principale del tuo Registro:

domain/strumento.js
  - Tocco spesso? Ogni volta che si aggiunge un stato o una regola → SÌ
  - Difficile da capire? Poche funzioni con nomi chiari → NO
  → Quadrante: Refactoring se blocca (bassa priorità ora)

application/registraPrestito.js
  - Tocco spesso? Quando cambia il flusso del prestito → OCCASIONALE
  - Difficile da capire? Dipende dalla separazione → DIPENDE
  → Da valutare caso per caso

presentation/ui.js
  - Tocco spesso? Ogni aggiunta di UI → SÌ
  - Difficile da capire? Se mischia regole e rendering → SPESSO SÌ
  → Quadrante: Refactoring prioritario (se contiene regole di dominio)

infrastructure/archivioLocalStorage.js
  - Tocco spesso? Raramente, salvo cambio archivio → NO
  - Difficile da capire? JSON.parse, try/catch → MODERATO
  → Quadrante: Lascia fermo (se funziona)

Quattro domande da porsi prima di refactorare

Prima di iniziare qualsiasi refactoring, rispondi a queste quattro domande:

1. "Devo toccare questo codice spesso?"
   Se no → probabilmente non vale la pena.

2. "Il refactoring rende future modifiche più veloci o più sicure?"
   Se non riesci a rispondere concretamente → probabilmente non vale.

3. "Ho una verifica del comportamento attuale?"
   Se no → scrivi prima la verifica, poi decidi se refactorare.

4. "Il rischio del refactoring è proporzionale al beneficio?"
   Refactoring su codice senza test = alto rischio. Vale solo se il beneficio è alto.

Cosa lasciare fermo — esempi concreti

Lascia fermo:

• codice funzionante che non viene mai toccato (es. adapter localStorage che funziona)
• logica corretta ma “brutta” in un file che non cresce (es. funzione di validazione semplice)
• struttura sub-ottimale in una parte del sistema stabile da settimane
• codice che non blocca test e non impedisce modifiche future

Refactora:

• codice in un file che tocchi ogni settimana e che rallenta ogni modifica
• dipendenze nascoste che rendono impossibile testare (alta priorità)
• regole di dominio nella UI che si duplicano ogni volta che aggiungi una schermata
• funzioni con più di tre responsabilità in un file che cresce continuamente

Come costruire il tuo piano di refactoring

1. Elenca tutte le parti del Registro che hai toccato nelle ultime due settimane.
2. Per ognuna: quanto era difficile fare la modifica? (facile / medio / difficile)
3. Classifica nella matrice.
4. Refactora partendo dal quadrante “Prioritario” — una cosa alla volta.

Procedura guidata

1. Apri il git log o ricorda le ultime modifiche fatte al Registro.
2. Elenca i file toccati nell’ultima settimana.
3. Per ogni file: è stato facile o difficile fare la modifica? Perché?
4. Compila la matrice con i tuoi file.
5. Scegli un solo elemento dal quadrante “Prioritario” — quello con più modifiche recenti.
6. Pianifica il refactoring in massimo tre passi.

Attività in classe

## Piano di refactoring

File toccati di recente e frequenza:
  - [file]: tocco [spesso/raramente]

Classificazione nella matrice:
  - Prioritario: [file]
  - Lascia fermo: [file]
  - Valuta: [file]

Refactoring scelto:
  - File: 
  - Problema attuale:
  - Beneficio atteso: 
  - Rischio: 
  - Verifica del comportamento attuale: 

Cosa lascio deliberatamente fermo e perché:

Spiegazione guidata per studiare

Il refactoring migliore non è quello che produce il codice più bello — è quello che rende le future modifiche più veloci o più sicure. Se un refactoring non ha questo effetto, è solo tempo speso a spostare codice.

Il punto centrale è: il criterio per refactorare è il costo futuro, non l’estetica. Un file “brutto” che nessuno tocca mai non è un problema urgente. Un file “mediocre” che si tocca ogni settimana e rallenta ogni modifica è un problema urgente.

Il rischio tipico è refactorare per “pulizia” senza un beneficio concreto. Questo introduce rischi (bug nelle modifiche) senza benefici proporzionali. La disciplina sta nel saper dire “questo lo lascio fermo” con lo stesso rigore con cui si dice “questo lo refactoro”.

Passo per passo nel progetto

1. Pensa all’ultima settimana di lavoro sul Registro — quali file hai toccato?
2. Per ogni file toccato: fare la modifica era facile o difficile? Perché?
3. Compila la matrice (4 quadranti) con i file del tuo progetto.
4. Scegli il file nel quadrante “Prioritario” con più modifiche recenti.
5. Pianifica un refactoring di massimo 2-3 passi con verifica intermedia.

Esempio da leggere lentamente

Analisi del progetto — ultima settimana:

File toccato: presentation/ui.js
  - Modifiche: aggiunto pulsante chiudi prestito, cambiato messaggio di errore
  - Difficoltà: MEDIO — ogni volta devo leggere 150 righe per capire cosa toccare
  - Motivo difficoltà: mischia regole di dominio, DOM e gestione errori
  → Quadrante: PRIORITARIO

File toccato: infrastructure/archivioLocalStorage.js
  - Modifiche: zero nelle ultime 3 settimane
  - Difficoltà: FACILE quando serve (ben isolato)
  → Quadrante: LASCIA FERMO

Decisione: refactoro ui.js — estraggo le regole di dominio in domain/,
           lascio fermo archivioLocalStorage.js — non è un problema.

Prova di comprensione

• Quali file del tuo Registro sono nel quadrante “Prioritario”?
• Hai mai refactorizzato qualcosa che poi non ha semplificato le modifiche future?
• Come decidi se un refactoring “vale la pena” prima di iniziarlo?

Errori da evitare

• refactorare per estetica senza un beneficio concreto sulle modifiche future;
• lasciare fermo codice che rende impossibile testare — è sempre prioritario;
• non avere una verifica del comportamento prima di iniziare;
• pianificare un refactoring enorme invece di scegliere un passo piccolo verificabile.

Prodotto da consegnare

Può essere:

• la matrice compilata con tutti i file del Registro classificati;
• il piano di refactoring scritto per il file nel quadrante prioritario;
• la lista di ciò che si è deciso di lasciare fermo, con motivazione.

Checklist di chiusura

• Ho classificato ogni parte del Registro nella matrice a quattro quadranti
• Ho identificato il quadrante “Prioritario” con almeno un file
• Ho pianificato il refactoring scelto in massimo tre passi
• Ho scritto esplicitamente cosa lascio fermo e perché
• Ho una verifica del comportamento attuale prima di iniziare

Domande per la revisione

• Il file che hai scelto per il refactoring era effettivamente nel quadrante prioritario?
• Hai trovato file che pensavi di dover refactorare ma che in realtà erano nel quadrante “Lascia fermo”?
• Quale è il beneficio concreto che ti aspetti dal refactoring scelto?

Risultato atteso

Alla fine lo studente deve saper dire:

Ho classificato i file del Registro nella matrice.
Il file [X] è nel quadrante "Prioritario" perché [motivo].
Ho pianificato questo refactoring: [descrizione in 2-3 passi].
Ho deciso di lasciare fermo [Y] perché [motivo concreto].

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.