O echipă moștenește un modul de facturare pe care nimeni nu îl înțelege pe deplin. Nu are teste care să protejeze comportamentul existent. Se propune un sprint pentru a-l „curăța”, iar planul este de a rescrie nucleul într-o structură nouă. Nimeni nu poate spune cum ar putea ști că noua versiune încă facturează clienții corect.
Acesta este un scenariu ilustrativ, nu un incident documentat. Descrie golul pe care un proiect de instruire în refactorizare trebuie să îl elimine: ingineri care pot vedea că codul este dezordonat, dar nu pot încă planifica o îmbunătățire limitată și nu pot demonstra că comportamentul a fost păstrat.
Acest ghid este destinat liderilor în domeniul capacitării în inginerie și managerilor de inginerie. Acesta acoperă modul de descriere a problemei de performanță, diagnosticarea lacunelor, pregătirea și practica proiectării, lucrul prin intermediul unui caz și evaluarea dacă abilitățile se transferă în munca reală. Este vorba despre proiectarea instruirii. Codul, testele și regulile din programul dvs. ar trebui validate de ingineri seniori din propriul stack.
Ce este un proiect de instruire pentru refactorizare?
Un proiect de instruire în refactorizare este o lucrare structurată pe cod vechi, al cărei scop este atât de a dezvolta capabilități, cât și de a îmbunătăți codul. Cursanții planifică o modificare mică, limitată, protejează comportamentul existent cu teste, îmbunătățesc designul în pași mici și demonstrează că nimic nu a fost defect. Codul se îmbunătățește și, mai important, inginerii exersează judecata de care vor avea nevoie asupra datoriilor tehnice reale.
Scurte
| Întrebare | Răspuns scurt |
|---|---|
| Care este sarcina? | Planificați și validați o îmbunătățire limitată a codului moștenit. |
| Ce punctaj obții? | Analiza riscurilor și dovezi că a fost menținut comportamentul existent. |
| Este o rescriere amplă un proiect de instruire bun? | De obicei nu. Ascunde abilitatea exersată și face dificilă demonstrarea comportamentului păstrat. |
| Este suficient un test despre refactorizarea șabloanelor? | Nu. Confirmă cerințele preliminare, dar nu și dacă un inginer poate planifica și valida o schimbare. |
| Cine validează conținutul? | Un manager de inginerie și un inginer senior care cunoaște baza de cod. |
| Ce nu poate rezolva antrenamentul? | Lipsa sculelor de testare, presiune de eliberare, proprietate neclară și lipsă de timp pentru lucrări de întreținere. |
| De unde știi că a funcționat? | Un caz nou, nevăzut, de cod vechi, evaluat conform unor criterii convenite, cu urmărire a lucrărilor reale. |
1. Descrieți problema de performanță
Începeți cu sarcina: planificați și validați o îmbunătățire a codului moștenit cu limite. „Delimitat” este cuvântul important. Cursantul alege o modificare suficient de mică pentru a fi finalizată și poate spune ce este în cadrul și în afara domeniului de aplicare.
Este util să fii precis în privința termenilor. Martin Fowler descrie refactorizarea ca fiind o tehnică controlată pentru îmbunătățirea designului unei baze de cod existente, alcătuită din transformări mici, care păstrează comportamentul. Expresia „care păstrează comportamentul” este ceea ce diferențiază refactorizarea de o rescriere și este ceea ce antrenamentul trebuie să facă vizibil. Metafora datoriei tehnice în sine a fost inventat de Ward Cunningham...iar discuția lui Fowler este o reamintire utilă a faptului că datoriile pot fi asumate în mod deliberat și prudent, așadar nu orice modul dezordonat este o greșeală care trebuie remediată.
Cartea lui Michael Feathers despre codul moștenit adoptă aceeași linie în practică. Descrierea editorului spune că îi învață pe dezvoltatori să scrie teste care asigură nu modifică aplicația fără intențieși pentru a aduce software-ul existent sub control fără o rescriere completă.
Scrieți declarația de performanță într-o singură propoziție și rugați un manager de inginerie să o verifice: „Având în vedere un modul vechi și un obiectiv definit, inginerul propune o modificare limitată, adaugă teste care definesc comportamentul actual, efectuează modificarea în pași mici și demonstrează că acest comportament este păstrat.”
2. Diagnosticați lacunele de învățare și context
Înainte de a construi orice, comparați sarcina necesară cu ceea ce practicați în activitățile dvs. actuale și evaluați. Trei întrebări diferențiază de obicei o lacună în instruire de altceva:
- Practica actuală folosește sarcina reală? Dacă instruirea acoperă modele de refactorizare în diapozitive, dar nimeni nu modifică vreodată codul netestat, nimeni nu a exersat comportamentul de protecție. Dacă evaluarea este un test cu variante multiple de răspuns privind mirosurile de cod, aceasta măsoară reamintirea.
- Care este cererea cognitivă? În taxonomia revizuită a lui Bloom, evaluarea siguranței unei schimbări se situează la nivelurile de analiză și evaluare, iar proiectarea planului și a testelor ajunge la nivelul de creare. Potrivirea activităților cu aceste niveluri este prezentată în ghidul nostru despre... potrivirea activităților de învățare cu taxonomia lui Bloom.
- Oare altceva în afară de abilitate intervine în cale? Verificați personalul, uneltele și procedurile. Dacă construcția durează o oră, nimeni nu va efectua teste des. Dacă lucrările de mentenanță nu sunt programate niciodată, inginerii vor refactoriza doar în secret. Raportați cauzele lipsei de instruire persoanelor care le pot remedia.
3. Proiectați o pregătire și o practică cu scop precis
După ce știi ce lacune poate fi acoperită de antrenament, acordă fiecărei etape o sarcină distinctă.
Pregătirea. Verificați cerințele preliminare cu o scurtă diagnosticare: cum funcționează cadrul dvs. de testare, ce este un test de caracterizare și cum analizează și integrează echipa dvs. Studiul în ritm propriu se potrivește acestei etape. O verificare a reamintirii confirmă doar cerințele preliminare.
Practică. Folosește proiecte de refactorizare sistematică cu o formă clară. Începe cu un eșantion mic și sigur, apoi treci la o parte reală, dar delimitată, a propriei baze de cod. Kata Gilded Rose este un punct de plecare bine-cunoscut pentru primul pas. Fișierul său README, întreținut de Emily Bache, recomandă scrierea testelor înainte de modificarea codului și prezintă exercițiul ca o practică în parcurgerea unor pași mici, rularea frecventă a testelor și îmbunătățirea designului puțin câte puțin. O secvență rezonabilă pentru fiecare proiect este: definirea obiectivului și a limitei, scrierea de teste care surprind ceea ce face codul astăzi, modificarea unui lucru pe rând, rularea testelor după fiecare pas și notarea a ceea ce ați învățat.
Parere. Legați feedback-ul de decizii, nu de un scor total. „Ați extras logica reducerii, dar testele dvs. au acoperit doar calea potrivită, așa că nu ați fi putut observa schimbarea de rotunjire” este mai util decât „3 din 5”.
Introducerea de informații live de la instructor sau evaluare asincronă? Introducerea în timp real adaugă cea mai mare valoare atunci când o alegere este ambiguă, de exemplu, dacă se va opri și se va adăuga un test lipsă sau se va continua. Revizuirea asincronă este suficientă atunci când cursanții își compară planul și testele cu o versiune adnotată de expert. Multe echipe folosesc ambele: mai întâi pregătirea în ritm propriu, apoi o sesiune facilitată pe cazurile dificile.
4. Lucrează printr-un exemplu realist
Ilustrativ. Un manager de inginerie ar trebui să valideze cazul și criteriile de răspuns înainte de utilizare.
Cazul. O funcție veche calculează totalul comenzii, inclusiv o reducere, o taxă și o regulă de livrare. Nu are teste. O echipă propune restructurarea întregului modul de facturare pentru a-l face „mai curat”.
Sarcina. Cursantul explică ce ar face, citează dovezile pe care le-ar aduna și spune de ce informații sau sprijin suplimentar are nevoie.
O primă încercare. „Aș împărți modulul în trei servicii și aș muta logica mai departe, apoi aș verifica numerele în etapele de pregătire.” Cursantul a ales o modificare majoră și o verificare manuală, târzie. Nu există nicio modalitate de a spune dacă versiunile vechi și noi sunt de acord în ceea ce privește cazurile limită.
Feedback și reîncercare. Recenzentul întreabă ce face funcția astăzi pentru un coș gol, o reducere care generează totalul negativ și un caz de rotunjire. Reîncercarea îi cere elevului să restrânge domeniul de aplicare la un singur comportament și să spună cum ar demonstra că acesta nu s-a schimbat.
O încercare mai puternică. „Aș lăsa structura modulului neschimbată deocamdată. Aș captura ceea ce returnează funcția totală a comenzilor astăzi pentru un set de intrări, inclusiv cazurile limită, ca teste. Apoi aș extrage calculul reducerii în propria funcție, aș rula testele după acel singur pas și aș opri. Aș observa că regula de livrare are un comportament pe care nu îl înțeleg și aș întreba un coleg înainte de a o atinge.” Observați că acest răspuns limitează modificarea, protejează mai întâi comportamentul și denumește ceea ce este necunoscut.
De ce fiecare răspuns este justificabil sau incomplet. Evaluați fiecare în funcție de criterii aprobate, nu de preferințele unui evaluator. Prima încercare poate fi o direcție pe termen lung sensibilă, dar este incompletă ca plan, deoarece nu conține dovezi ale unui comportament păstrat. Încercarea mai puternică este mică, verificabilă și sinceră în ceea ce privește incertitudinea.
5. Evaluarea capacității și planificarea transferului
Dovada capacității este performanța într-un caz nou de cod moștenit pe care cursantul nu l-a văzut. Evaluați analiza riscurilor și dovezile că comportamentul a fost păstrat. O rubrică simplă folosește o scală de la 0 la 2 per criteriu:
| Criteriu | Dovezi observabile |
|---|---|
| Executarea sarcinilor | Planifică și validează o îmbunătățire limitată a codului moștenit și înregistrează acțiunea și dovezile din spatele acesteia. |
| Raţionament | Explică constrângerile, alternativele și incertitudinea și verifică riscurile și dovezile că a fost menținut comportamentul. |
| Limite | Folosește proceduri aprobate și solicită ajutor atunci când informațiile sau autoritatea sunt insuficiente. |
Ancore: 0 este absent sau nejustificat, 1 este parțial cu omisiuni relevante, iar 2 este complet și justificat conform criteriilor convenite. Definiți separat erorile critice, cum ar fi schimbarea comportamentului fără niciun test care să le fi observat, astfel încât un scor general să nu poată ascunde una. Această rubrică este o propunere, nu un standard de pregătire validat: adaptați-o cu un manager de inginerie și pilotați-o. Ghidul nostru pentru proiectarea unei practici interactive cu feedback util arată cum se scrie feedback care se leagă de decizii.
Planificați transferul în mod deliberat. După exercițiu, dați fiecărui inginer o mică datorie reală pe care să o rezolve cu un evaluator sau realizați o scurtă retrospectivă a unei modificări recente care a dus la o problemă. Verificați transferul după o expunere adecvată la lucrări reale, nu imediat după atelier.
Unde ajută livrarea interactivă
Formatele interactive sunt utile acolo unde toată lumea ar trebui să își facă un angajament înainte de a vedea grupul. Într-o sesiune live, un facilitator poate afișa un scurt fragment de text existent, poate ruga fiecare inginer să trimită prima modificare pe care ar face-o și cum ar demonstra că este sigură, apoi poate dezvălui distribuția înainte de discuție. Aceeași solicitare poate fi rulată în ritm propriu pentru pregătire. AhaSlides acceptă învățarea interactivă și trecerea de la livrarea live la cea în ritm propriu. Este un instrument de prezentare și învățare, nu un loc pentru a rula sau analiza cod, așa că rulați refactorizarea în sine în propriul mediu. Verificați orice funcție specifică de creare, feedback sau raportare pe care intenționați să vă bazați în raport cu propriul flux de lucru. Pentru îndrumări privind alegerea formatelor, consultați articolul nostru despre când să folosim învățarea adaptivă, interactivă și live.
Măsoară ce s-a schimbat
Decideți în avans ce ar demonstra că inginerii pot îndeplini sarcina. Comparați calitatea analizei de risc și dovezile comportamentului păstrat într-un caz nevăzut, cu o valoare de referință. Definiți cine este inclus, numitorul și momentul. Dacă rezultatele se îmbunătățesc, verificați ce s-a mai schimbat în aceeași perioadă, cum ar fi instrumente de testare noi, o construcție mai rapidă sau o schimbare de proprietar, înainte de a acorda credit instruirii.
Constrângeri care pot rămâne
- Timp pentru lucrări de întreținere. Dacă lucrările de gestionare a datoriilor nu sunt niciodată programate, inginerii calificați tot nu au unde să folosească această abilitate.
- Scule de testare. Fără un ham de testare utilizabil sau o construcție rapidă, pașii mici și verificările frecvente sunt greu de susținut.
- Acoperirea cazului. Un caz istoric prezintă câteva tipuri de risc. Un scor nu descrie judecata unui inginer în general.
- Judecând când nu este necesar să se refactorizeze. Unele coduri sunt mai bine lăsate neschimbate, înlocuite sau retrase, iar această decizie implică mai mult decât abilități.
- Transfer. Performanța într-un kata nu este aceeași cu performanța într-un modul de producție sub presiunea livrării.
Numiți-le sponsorilor din timp și planificați remedieri separate. Instruirea îmbunătățește ceea ce un inginer poate planifica și demonstra. Nu creează timpul sau uneltele necesare.
Întrebări frecvente
Ce este un proiect de instruire pentru refactorizare?
Este o practică structurată pe cod vechi, în care inginerii planifică o mică modificare, protejează comportamentul existent cu teste, modifică designul în pași mici și demonstrează că nimic nu a fost defect.
Este o rescriere completă o modalitate bună de a afla despre datoria tehnică?
De obicei nu. O rescriere este mare, greu de validat și ascunde abilitatea pe care vrei să o dezvolți. O modificare delimitată, cu teste care surprind comportamentul actual, face ca raționamentul să fie vizibil.
Cum evaluezi dacă inginerii pot refactoriza în siguranță?
Prezentați un nou caz de cod vechi și evaluați analiza riscurilor și dovezile că comportamentul a fost păstrat în funcție de criteriile convenite. Un test despre modelele de refactorizare confirmă doar cerințele preliminare.
Ai nevoie de o bază de cod exemplu pentru antrenament?
Ai nevoie de un loc unde să exersezi în siguranță. Multe echipe încep cu un kata public și apoi trec la o parte delimitată a propriului cod. Managerul tău de inginerie ar trebui să confirme că este potrivit codul.
Unde să încep
Alegeți un tip de modificare moștenită, mică și recurentă, în baza de cod. Scrieți declarația de performanță, rugați un manager de inginerie să valideze cazul și testele care ar demonstra un comportament păstrat și elaborați o rubrică cu trei criterii, cu o scală de la 0 la 2 și o listă de erori critice. Testați-o cu un grup mic înainte de a o implementa.
Pentru a vedea cum un exercițiu de refactorizare ar putea fi derulat live cu propria echipă și reutilizat ulterior în ritmul propriu, explorează AhaSlides.
