Template per Piano di Refactoring di una Funzione
Per chi deve ripulire una funzione complessa senza romperla: ottieni una diagnosi dei code smell, una sequenza di micro-refactoring sicuri (uno alla volta), il before/after di ogni passo e una checklist di test che garantisce comportamento invariato.
Esempio di output
DIAGNOSI Funzione: calcolaPrezzoFinale() — 64 righe, complessita ciclomatica ~14. Code smell rilevati: | # | Smell | Posizione | Gravita | |---|-------|-----------|---------| | 1 | Long Method (64 righe, 4 responsabilita) | intera funzione | Alta | | 2 | Magic numbers (0.22, 0.1) | righe 18, 27 | Media | | 3 | Nested conditionals (3 livelli) | righe 30-48 | Media | | 4 | Nome poco chiaro: $x, $t | righe 12-14 | Bassa | INVARIANTI DA PRESERVARE: stesso prezzo di output a parita di input; stessa gestione sconto a zero; nessun cambio di firma pubblica. PIANO DI REFACTORING (passi atomici, rischio crescente) Passo 0 — Rete di sicurezza | Rischio: nullo Aggiungi test di caratterizzazione su 5 casi (sconto 0, sconto max, iva inclusa/esclusa, importo 0, negativo). Passo 1 — Estrai costanti nominate | Rischio: basso // before prezzo * 0.22 // after prezzo * ALIQUOTA_IVA Verifica: i test del Passo 0 restano verdi. Passo 2 — Estrai metodo calcolaIva() | Rischio: basso Sposta righe 18-22 in un metodo privato puro. Passo 3 — Sostituisci nested if con guard clauses | Rischio: medio Riduce annidamento da 3 a 1 livello; attenzione all'ordine di valutazione dello sconto. BUG SOSPETTI (fuori dal refactoring) - Riga 41: sconto non clampato puo rendere il prezzo negativo. Da verificare con il PO, NON risolvere dentro il refactoring.
Domande frequenti
No, per definizione. Il prompt impone refactoring a comportamento invariato (behavior-preserving): ogni passo dichiara cosa NON deve cambiare e include come verificarlo. Eventuali bug scoperti durante la diagnosi vengono segnalati a parte, separati dai passi di refactoring.
Perche i micro-refactoring incrementali sono verificabili e reversibili: se un passo introduce un problema, sai esattamente quale. Il formato spezza il lavoro in passi atomici ordinati per rischio crescente, ciascuno committabile da solo.
Si, e in quel caso il primo passo del piano sara proprio aggiungere test di caratterizzazione che fissano il comportamento attuale, cosi i refactoring successivi sono protetti. Il prompt lo prevede esplicitamente.
Vuoi un template su misura?
Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.