Un team eredita un modulo di fatturazione che nessuno comprende appieno. Non ci sono test che proteggano il comportamento esistente. Viene proposto uno sprint per "sistemarlo" e il piano è di riscrivere il nucleo con una nuova struttura. Nessuno sa come si possa essere certi che la nuova versione continui ad addebitare correttamente i clienti.
Questo è uno scenario esemplificativo, non un incidente documentato. Descrive la lacuna che un progetto di formazione sul refactoring deve colmare: ingegneri che si rendono conto che il codice è disordinato, ma non sono ancora in grado di pianificare un miglioramento circoscritto e dimostrare che il comportamento previsto è stato preservato.
Questa guida è destinata ai responsabili e ai manager dell'abilitazione ingegneristica. Illustra come descrivere il problema di prestazioni, diagnosticare le lacune, progettare la preparazione e la pratica, analizzare un caso pratico e valutare se le competenze acquisite sono trasferibili al lavoro reale. Si tratta di progettazione della formazione. Il codice, i test e le regole del programma devono essere validati da ingegneri senior sulla propria piattaforma.
Che cos'è un progetto di formazione sul refactoring?
Un progetto di training sul refactoring è un lavoro strutturato su codice legacy, il cui scopo è sia quello di sviluppare competenze che di migliorare il codice stesso. I partecipanti pianificano una piccola modifica circoscritta, proteggono il comportamento esistente con dei test, migliorano la progettazione a piccoli passi e dimostrano che non si sono verificati problemi. Il codice migliora e, cosa ancora più importante, gli ingegneri esercitano la capacità di giudizio necessaria per gestire il debito tecnico reale.
I fatti in breve
| La Domanda | Risposta breve |
|---|---|
| Qual è il compito? | Pianificare e convalidare un miglioramento circoscritto del codice legacy. |
| Che punteggio ottieni? | Analisi dei rischi e prove del mantenimento dei comportamenti preesistenti. |
| Una revisione completa è un buon progetto di formazione? | Di solito no. Nasconde l'abilità che si sta esercitando e rende difficile dimostrare il comportamento consolidato. |
| È sufficiente un quiz sui modelli di refactoring? | No. Conferma i prerequisiti, ma non se un ingegnere è in grado di pianificare e convalidare una modifica. |
| Chi convalida i contenuti? | Un responsabile dell'ingegneria e un ingegnere senior che conosce il codice sorgente. |
| Cosa non si può risolvere con l'allenamento? | Mancanza di strumenti di prova, pressione di rilascio insufficiente, responsabilità poco chiara e mancanza di tempo per i lavori di manutenzione. |
| Come fai a sapere che ha funzionato? | Un nuovo caso di codice legacy inedito, valutato in base a criteri concordati, con successivo approfondimento su casi reali. |
1. Descrivi il problema di prestazioni
Iniziate con il compito: pianificare e validare un miglioramento circoscritto del codice legacy. "Circoscritto" è la parola chiave. Chi apprende sceglie una modifica sufficientemente piccola da poter essere completata e sa definire cosa rientra e cosa non rientra nell'ambito del progetto.
È utile essere precisi sui termini. Martin Fowler descrive il refactoring come una tecnica controllata per migliorare la progettazione di una base di codice esistente, composto da piccole trasformazioni che preservano il comportamento. La frase "che preserva il comportamento" è ciò che distingue il refactoring da una riscrittura, ed è ciò che la formazione deve rendere visibile. La metafora del debito tecnico stesso fu coniato da Ward Cunninghame la discussione di Fowler è un utile promemoria del fatto che il debito può essere assunto in modo deliberato e prudente, quindi non ogni modulo disordinato è un errore da correggere.
Il libro di Michael Feathers sul codice legacy segue la stessa linea in materia di pratica. La descrizione dell'editore afferma che insegna agli sviluppatori a scrivere test che garantiscono non stanno modificando l'applicazione involontariamentee per tenere sotto controllo il software esistente senza doverlo riscrivere completamente.
Riassumi la prestazione in una sola frase e falla controllare a un responsabile tecnico: "Dato un modulo legacy e un obiettivo definito, il tecnico propone una modifica circoscritta, aggiunge test che individuano il comportamento attuale, implementa la modifica gradualmente e dimostra che il comportamento viene preservato."
2. Diagnosticare le lacune di apprendimento e di contesto
Prima di iniziare qualsiasi attività, confronta il compito richiesto con le pratiche e le valutazioni che svolgi attualmente. Tre domande solitamente distinguono una lacuna formativa da qualcos'altro:
- La pratica attuale si basa sul compito reale? Se la formazione si concentra sui modelli di refactoring presentati in slide, ma nessuno modifica mai il codice non testato, nessuno ha praticato il comportamento di protezione. Se la valutazione consiste in un test a risposta multipla sui "code smell" (cattive pratiche di programmazione), misura la mera memorizzazione.
- Qual è il carico cognitivo richiesto? Nella tassonomia rivista di Bloom, valutare se un cambiamento è sicuro si colloca ai livelli di analisi e valutazione, mentre la progettazione del piano e dei test raggiunge il livello di creazione. L'abbinamento delle attività a questi livelli è trattato nella nostra guida a abbinamento delle attività di apprendimento alla tassonomia di Bloom.
- C'è qualcos'altro, oltre alla mancanza di abilità, che ostacola il processo? Verifica il personale, gli strumenti e le procedure. Se la compilazione richiede un'ora, nessuno eseguirà test frequentemente. Se la manutenzione non viene mai programmata, gli ingegneri effettueranno il refactoring solo di nascosto. Segnala le cause non legate alla formazione alle persone competenti per risolverle.
3. Progettare una preparazione e una pratica mirate
Una volta individuate le lacune che la formazione può colmare, assegnate a ciascuna fase un compito specifico.
Preparazione. Verifica i prerequisiti con una breve diagnosi: come funziona il tuo framework di test, cos'è un test di caratterizzazione e come il tuo team esamina e integra i dati. Lo studio autonomo è adatto a questa fase. Un controllo mnemonico conferma solo i prerequisiti.
Pratica. Utilizza progetti di refactoring sistematici con una struttura chiara. Inizia con un piccolo campione sicuro, poi passa a una parte reale ma circoscritta della tua codebase. Il kata Gilded Rose è un punto di partenza ben noto per il primo passo. Il suo README, gestito da Emily Bache, Si consiglia di scrivere dei test prima di modificare il codice. e inquadra l'esercizio come una pratica che consiste nel fare piccoli passi, eseguire i test frequentemente e migliorare il design gradualmente. Una sequenza sensata per ogni progetto è: definire l'obiettivo e i limiti, scrivere test che catturino il comportamento attuale del codice, modificare una cosa alla volta, eseguire i test dopo ogni passaggio e annotare ciò che si è appreso.
Feedback. Collega il feedback alle decisioni, non a un punteggio totale. "Hai estratto la logica dello sconto, ma i tuoi test hanno coperto solo il caso ideale, quindi non avresti potuto notare la modifica dell'arrotondamento" è più utile di "3 su 5".
Intervento in diretta del docente o revisione asincrona? L'input in tempo reale è più utile quando una scelta è ambigua, ad esempio se fermarsi e aggiungere un test mancante o continuare. La revisione asincrona è sufficiente quando gli studenti confrontano il loro piano e i test con una versione annotata da un esperto. Molti team utilizzano entrambi i metodi: prima la preparazione autonoma, poi una sessione guidata sui casi più complessi.
4. Analizza un esempio realistico
A scopo illustrativo. Un responsabile tecnico dovrebbe convalidare il caso e i criteri di risposta prima dell'utilizzo.
Il caso. Una funzione legacy calcola il totale di un ordine, inclusi sconti, tasse e regole di spedizione. Non è dotata di test. Un team propone di ristrutturare l'intero modulo di fatturazione per renderlo più "pulito".
Il compito. Lo studente spiega cosa farebbe, cita le prove che raccoglierebbe e indica di quali ulteriori informazioni o supporto ha bisogno.
Un primo tentativo. "Dividerei il modulo in tre servizi e sposterei la logica, poi verificherei i numeri nell'ambiente di staging." Chi sta imparando ha optato per una modifica sostanziale e per una verifica manuale tardiva. Non c'è modo di sapere se la vecchia e la nuova versione coincidono nei casi limite.
Invia feedback e riprova. Il revisore chiede cosa fa attualmente la funzione in caso di carrello vuoto, di sconto che rende il totale negativo e di arrotondamento. La seconda domanda chiede allo studente di restringere l'ambito a un solo comportamento e di spiegare come dimostrerebbe che non è cambiato.
Un tentativo più deciso. "Per ora lascerei inalterata la struttura del modulo. Catturerei il valore restituito dalla funzione di totale dell'ordine per una serie di input, inclusi i casi limite, da utilizzare come test. Poi estrarrei il calcolo dello sconto in una funzione separata, eseguirei i test dopo questo singolo passaggio e mi fermerei. Prenderei nota del comportamento della regola di spedizione che non comprendo e chiederei il parere di un collega prima di modificarla." Si noti che questa risposta delimita la modifica, protegge prima il comportamento e identifica ciò che è sconosciuto.
Perché ciascuna risposta è difendibile o incompleta. Valutate ciascuna proposta in base a criteri approvati, non alle preferenze del revisore. Il primo tentativo può rappresentare una direzione sensata a lungo termine, ma è incompleto come piano, perché non fornisce alcuna prova del comportamento mantenuto nel tempo. Il tentativo più solido è circoscritto, verificabile e onesto riguardo all'incertezza.
5. Valutare le capacità e pianificare il trasferimento
La prova della capacità è data dalla prestazione su un nuovo caso di codice legacy che il discente non ha mai visto. Valutare l'analisi del rischio e la prova che il comportamento è stato preservato. Una semplice griglia di valutazione utilizza una scala da 0 a 2 per ciascun criterio:
| Criterio | Prove osservabili |
|---|---|
| Esecuzione dell'attività | Pianifica e convalida un miglioramento circoscritto del codice legacy, documentando l'azione intrapresa e le relative prove. |
| Ragionamento | Spiega i vincoli, le alternative e l'incertezza, e verifica i rischi e le prove che il comportamento sia stato mantenuto. |
| Confini | Utilizza procedure approvate e chiede aiuto quando le informazioni o l'autorità non sono sufficienti. |
Ancore: 0 è assente o non supportato, 1 è parziale con omissioni rilevanti e 2 è completo e giustificato in base a criteri concordati. Definire separatamente gli errori critici, come il cambiamento di comportamento senza alcun test che avrebbe potuto rilevarlo, in modo che un punteggio complessivo non possa nasconderne uno. Questa rubrica è una proposta, non uno standard di prontezza convalidato: adattarla con un responsabile dell'ingegneria e testarla. La nostra guida a progettare attività interattive con feedback utili Mostra come scrivere un feedback che si colleghi alle decisioni prese.
Pianifica il trasferimento delle competenze in modo mirato. Dopo l'esercitazione, assegna a ciascun ingegnere un piccolo problema concreto da risolvere con un revisore, oppure fai una breve analisi retrospettiva su una modifica recente che ha causato un malfunzionamento. Verifica il trasferimento delle competenze dopo un'adeguata esperienza lavorativa reale, non subito dopo il workshop.
Dove la consegna interattiva aiuta
I formati interattivi aiutano a far sì che tutti si impegnino prima di vedere il gruppo. In una sessione live, un facilitatore può mostrare un breve frammento di codice legacy, chiedere a ciascun ingegnere di inviare la prima modifica che apporterebbe e come ne dimostrerebbe la sicurezza, quindi rivelare la distribuzione prima della discussione. Lo stesso prompt può essere eseguito in modalità autogestita per la preparazione. AhaSlides supporta l'apprendimento interattivo e il passaggio tra la modalità live e quella autogestita. È uno strumento di presentazione e apprendimento, non un luogo in cui eseguire o analizzare il codice, quindi esegui il refactoring vero e proprio nel tuo ambiente. Verifica qualsiasi funzione specifica di authoring, feedback o reporting su cui intendi fare affidamento rispetto al tuo flusso di lavoro. Per indicazioni sulla scelta dei formati, consulta il nostro articolo su quando utilizzare l'apprendimento adattivo, interattivo e in diretta.
Misurare ciò che è cambiato
Decidete in anticipo cosa dimostrerebbe che gli ingegneri sono in grado di svolgere il compito. Confrontate la qualità dell'analisi dei rischi e le prove del comportamento mantenuto in un caso non visto in precedenza, rispetto a una linea di base. Definite chi è incluso, il denominatore e la tempistica. Se i risultati migliorano, verificate cos'altro è cambiato nello stesso periodo, come nuovi strumenti di test, un processo di sviluppo più rapido o un cambio di proprietà, prima di attribuire il merito alla formazione.
Vincoli che potrebbero rimanere
- È tempo di effettuare lavori di manutenzione. Se i lavori di recupero crediti non vengono mai programmati, gli ingegneri qualificati non hanno comunque un posto dove mettere a frutto le proprie competenze.
- Strumenti di prova. Senza un sistema di test utilizzabile o un processo di sviluppo rapido, è difficile mantenere piccoli passi e controlli frequenti.
- Copertura del caso. Un caso di studio precedente illustra diverse tipologie di rischio. Un punteggio non descrive il giudizio di un ingegnere in generale.
- Valutare quando non è necessario effettuare un refactoring. Alcuni codici è meglio lasciarli stare, sostituirli o abbandonarli, e questa decisione dipende da ben più che dalla sola competenza.
- Trasferimento. Le prestazioni in un kata non sono le stesse delle prestazioni in un modulo di produzione sotto pressione per la consegna.
Segnalate tempestivamente questi problemi agli sponsor e pianificate soluzioni separate. La formazione migliora ciò che un ingegnere può pianificare e dimostrare, ma non crea il tempo o gli strumenti necessari.
Domande frequenti
Che cos'è un progetto di formazione sul refactoring?
Si tratta di una pratica strutturata su codice legacy in cui gli ingegneri pianificano una piccola modifica, proteggono il comportamento esistente con dei test, modificano il progetto a piccoli passi e dimostrano che non si sono verificati problemi.
Riscrivere completamente il testo è un buon modo per imparare a gestire il debito tecnico?
Di solito no. Una riscrittura completa è complessa, difficile da validare e nasconde la funzionalità che si desidera sviluppare. Una modifica circoscritta, con test che catturano il comportamento attuale, rende visibile il ragionamento alla base della scelta.
Come si valuta se gli ingegneri possono effettuare un refactoring in sicurezza?
Presenta un nuovo caso di codice legacy e valuta l'analisi del rischio e le prove che il comportamento sia stato preservato rispetto ai criteri concordati. Un quiz sui modelli di refactoring serve solo a verificare i prerequisiti.
Hai bisogno di un esempio di codice sorgente per la formazione?
Hai bisogno di un posto sicuro dove poterti esercitare. Molti team iniziano con un kata pubblico per poi passare a una porzione circoscritta del proprio codice. Il tuo responsabile tecnico dovrebbe confermare che il codice sia adatto.
Dove iniziare
Scegliete una piccola modifica ricorrente al codice esistente. Scrivete una dichiarazione sulle prestazioni, fate convalidare il caso da un responsabile tecnico e definite i test che dimostrerebbero il mantenimento del comportamento desiderato. Infine, create una griglia di valutazione a tre criteri con una scala da 0 a 2 e un elenco di errori critici. Prima di implementarla su larga scala, testatela con un piccolo gruppo.
Per scoprire come un esercizio decisionale di refactoring può essere svolto in tempo reale con il tuo team e riutilizzato in seguito in autonomia, esplora AhaSlides.
