Isang pangkat ang nagmana ng isang modyul sa pagsingil na walang lubos na nakakaintindi. Wala itong mga pagsubok na nagpoprotekta sa umiiral na pag-uugali. Isang sprint ang iminungkahi upang "linisin ito", at ang plano ay muling isulat ang core sa isang bagong istraktura. Walang makapagsasabi kung paano nila malalaman na ang bagong bersyon ay naniningil pa rin nang tama sa mga customer.
Ito ay isang naglalarawang senaryo, hindi isang dokumentadong insidente. Inilalarawan nito ang kakulangang kailangang tapusin ng isang proyekto sa pagsasanay sa refactoring: mga inhinyero na nakakakita na ang code ay magulo, ngunit hindi pa makapagplano ng isang limitadong pagpapabuti at maipakita na ang pag-uugali ay napanatili.
Ang gabay na ito ay para sa mga engineering enablement lead at engineering manager. Saklaw nito kung paano ilarawan ang problema sa pagganap, suriin ang mga kakulangan, paghahanda at pagsasanay sa disenyo, pag-aralan ang isang kaso at suriin kung ang kasanayan ay maisasalin sa totoong trabaho. Ito ay tungkol sa disenyo ng pagsasanay. Ang code, mga pagsubok at mga patakaran sa iyong programa ay dapat na mapatunayan ng mga senior engineer sa iyong sariling stack.
Ano ang isang proyekto sa pagsasanay sa refactoring?
Ang isang proyekto sa pagsasanay sa refactoring ay isang nakabalangkas na gawain sa legacy code, kung saan ang layunin ay bumuo ng kakayahan pati na rin upang mapabuti ang code. Nagpaplano ang mga mag-aaral ng isang maliit at limitadong pagbabago, pinoprotektahan ang umiiral na pag-uugali gamit ang mga pagsubok, pinapabuti ang disenyo sa maliliit na hakbang at nagpapakita ng ebidensya na walang nasira. Gumaganda ang code, at, higit sa lahat, isinasagawa ng mga inhinyero ang paghatol na kakailanganin nila sa totoong teknikal na utang.
Mabilis na katotohanan
| Tanong | Maikling sagot |
|---|---|
| Ano ang gawain? | Magplano at magpatunay ng isang bounded legacy code improvement. |
| Ano ang iyong iskor? | Pagsusuri ng panganib, at ebidensya na napanatili ang umiiral na pag-uugali. |
| Magandang proyekto ba sa pagsasanay ang malawak na pagsulat muli? | Kadalasan hindi. Itinatago nito ang kasanayang isinasagawa at ginagawang mahirap ipakita ang napanatiling pag-uugali. |
| Sapat na ba ang isang pagsusulit tungkol sa mga pattern ng refactoring? | Hindi. Kinukumpirma nito ang mga kinakailangan, ngunit hindi kung kayang planuhin at patunayan ng isang inhinyero ang isang pagbabago. |
| Sino ang nagpapatunay sa nilalaman? | Isang engineering manager at isang senior engineer na alam ang codebase. |
| Ano ang hindi kayang ayusin ng pagsasanay? | Nawawalang mga kagamitang pangsubok, pressure sa paglabas, hindi malinaw na pagmamay-ari, at walang oras para sa gawaing pagpapanatili. |
| Paano mo nalaman na gumana ito? | Isang bago, hindi pa nakikitang kaso ng legacy-code, na binigyan ng puntos batay sa napagkasunduang pamantayan, na may kasamang follow-up sa totoong trabaho. |
1. Ilarawan ang problema sa pagganap
Magsimula sa gawain: planuhin at patunayan ang isang bounded legacy code improvement. "Bounded" ang mahalagang salita. Ang mag-aaral ay pumipili ng isang pagbabago na sapat ang liit upang matapos, at masasabi kung ano ang nasa loob at labas ng saklaw.
Nakakatulong ang pagiging tumpak sa mga termino. Inilalarawan ni Martin Fowler ang refactoring bilang isang kontroladong pamamaraan para sa pagpapabuti ng disenyo ng isang umiiral na code base, binubuo ng maliliit at nakapagpapanatili ng pag-uugali. Ang pariralang "nagpapanatili ng pag-uugali" ang siyang naghihiwalay sa refactoring mula sa isang muling pagsulat, at ito ang dapat ipakita ng pagsasanay. Ang mismong metapora ng teknikal na utang ay nilikha ni Ward Cunningham, at ang talakayan ni Fowler ay isang kapaki-pakinabang na paalala na ang utang ay maaaring tanggapin nang may sinasadya at maingat, kaya hindi lahat ng makalat na modyul ay isang pagkakamali na dapat itama.
Ang aklat ni Michael Feathers tungkol sa legacy code ay may parehong prinsipyo sa pagsasagawa. Sinasabi ng deskripsyon ng tagapaglathala nito na tinuturuan nito ang mga developer na magsulat ng mga pagsubok na nagsisiguro hindi nila sinasadyang binabago ang aplikasyon, at upang makontrol ang umiiral na software nang walang ganap na muling pagsusulat.
Isulat ang pahayag ng pagganap sa isang pangungusap at ipasuri ito sa isang engineering manager: “Dahil sa isang legacy module at isang tinukoy na layunin, ang engineer ay nagmumungkahi ng isang limitadong pagbabago, nagdaragdag ng mga pagsubok na tumutukoy sa kasalukuyang pag-uugali, ginagawa ang pagbabago sa maliliit na hakbang at ipinapakita na ang pag-uugali ay napanatili.”
2. Suriin ang mga kakulangan sa pagkatuto at konteksto
Bago ka bumuo ng kahit ano, ihambing ang kinakailangang gawain sa kung ano ang iyong kasalukuyang mga aktibidad na isinasagawa at sinusuri. Tatlong tanong ang karaniwang naghihiwalay sa isang training gap mula sa ibang bagay:
- Ginagamit ba ng kasalukuyang kasanayan ang totoong gawain? Kung ang pagsasanay ay sumasaklaw sa mga refactoring pattern sa mga slide, ngunit walang sinuman ang nagbabago ng hindi pa nasusubukang code, walang sinuman ang nagsanay ng pagprotekta sa pag-uugali. Kung ang pagtatasa ay isang multiple-choice na pagsusulit sa mga code smell, sinusukat nito ang recall.
- Ano ang pangangailangang kognitibo? Sa binagong taxonomy ni Bloom, ang paghusga kung ligtas ang isang pagbabago ay nakasalalay sa mga antas ng pagsusuri at pagsusuri, at ang pagdidisenyo ng plano at mga pagsubok ay umaabot sa antas ng paglikha. Ang pagtutugma ng mga aktibidad sa mga antas na iyon ay sakop sa aming gabay sa pagtutugma ng mga aktibidad sa pagkatuto sa Bloom's Taxonomy.
- May iba pa bang nakaharang bukod sa kasanayan? Suriin ang mga tauhan, kagamitan, at mga pamamaraan. Kung ang pagtatayo ay aabutin ng isang oras, walang madalas na magsasagawa ng mga pagsubok. Kung ang mga gawaing pagpapanatili ay hindi kailanman naka-iskedyul, ang mga inhinyero ay lihim na magre-refactor. Iulat ang mga sanhi na hindi dahil sa pagsasanay sa mga taong maaaring mag-ayos ng mga ito.
3. Magdisenyo ng may layuning paghahanda at pagsasanay
Kapag alam mo na kung aling mga puwang ang maaaring isara ng pagsasanay, bigyan ang bawat yugto ng isang natatanging trabaho.
Paghahanda Suriin ang mga kinakailangan gamit ang isang maikling pagsusuri: kung paano gumagana ang balangkas ng iyong pagsubok, ano ang isang pagsubok sa paglalarawan ng karakter, at kung paano sinusuri at pinagsasama-sama ng iyong pangkat. Angkop sa yugtong ito ang pag-aaral na may sariling bilis. Kinukumpirma lamang ng pagsusuri sa paggunita ang mga kinakailangan.
Practice. Gumamit ng sistematikong mga proyekto sa refactoring na may malinaw na hugis. Magsimula sa isang maliit at ligtas na sample, pagkatapos ay lumipat sa isang tunay ngunit may hangganang bahagi ng iyong sariling codebase. Ang Gilded Rose kata ay isang kilalang panimulang punto para sa unang hakbang. Ang README nito, na pinapanatili ni Emily Bache, inirerekomenda ang pagsulat ng mga pagsubok bago baguhin ang code at ibinabalangkas ang pagsasanay bilang pagsasanay sa pamamagitan ng paggawa ng maliliit na hakbang, madalas na pagpapatakbo ng mga pagsubok, at unti-unting pagpapabuti ng disenyo. Ang isang makatwirang pagkakasunod-sunod para sa bawat proyekto ay: tukuyin ang layunin at ang hangganan, sumulat ng mga pagsubok na kumukuha sa ginagawa ng code ngayon, baguhin ang isang bagay sa isang pagkakataon, patakbuhin ang mga pagsubok pagkatapos ng bawat hakbang, at isulat ang iyong natutunan.
Feedback. Iugnay ang feedback sa mga desisyon, hindi sa kabuuang iskor. Mas kapaki-pakinabang ang "Kinuha mo ang lohika ng diskwento, ngunit ang iyong mga pagsusulit ay sumasaklaw lamang sa masayang landas, kaya maaaring hindi mo napansin ang pagbabago sa pag-ikot" kaysa sa "3 sa 5".
Live na input ng instruktor o asynchronous na pagsusuri? Ang live input ay nagdaragdag ng pinakamalaking halaga kapag ang isang pagpipilian ay hindi malinaw, halimbawa kung ititigil at idaragdag ang isang nawawalang pagsusulit o magpapatuloy. Sapat na ang asynchronous na pagsusuri kapag inihambing ng mga mag-aaral ang kanilang plano at mga pagsusulit sa isang may anotasyong bersyon ng eksperto. Maraming mga koponan ang gumagamit ng pareho: paghahanda sa sarili muna, pagkatapos ay isang pinadali na sesyon sa mga mahihirap na kaso.
4. Gumawa ng isang makatotohanang halimbawa
Paglalarawan. Dapat patunayan ng isang engineering manager ang kaso at ang pamantayan ng sagot bago gamitin.
Ang kaso. Kinakalkula ng isang legacy function ang kabuuang order, kabilang ang diskwento, buwis, at shipping rule. Wala itong mga pagsubok. Iminumungkahi ng isang team na baguhin ang istruktura ng buong billing module para gawin itong "mas malinis".
Ang gawain. Ipapaliwanag ng mag-aaral ang kanilang gagawin, babanggitin ang ebidensyang kanilang makakalap, at sasabihin kung anong karagdagang impormasyon o suporta ang kailangan nila.
Isang unang pagsubok. “Hahatiin ko ang modyul sa tatlong serbisyo at ililipat ang lohika, pagkatapos ay susuriin ang mga numero sa staging.” Pinili ng mag-aaral ang isang malaking pagbabago at isang huli at manu-manong pagsusuri. Walang paraan upang malaman kung ang luma at bagong bersyon ay magkatugma sa mga edge case.
Magbigay ng feedback at subukan muli. Itatanong ng tagasuri kung ano ang ginagawa ng function ngayon para sa isang walang laman na basket, isang diskwento na ginagawang negatibo ang kabuuan, at isang rounding case. Hihilingin sa mag-aaral na paliitin ang saklaw sa isang kilos at sabihin kung paano nila mapapatunayan na hindi ito nagbago.
Isang mas malakas na pagtatangka. "Iiwan ko muna ang istruktura ng module. Kukunin ko ang ibinabalik ng order total function ngayon para sa isang set ng input, kabilang ang mga edge case, bilang mga pagsubok. Pagkatapos ay kukunin ko ang discount calculation sa sarili nitong function, patakbuhin ang mga pagsubok pagkatapos ng isang hakbang na iyon, at ititigil. Pansinin ko na ang shipping rule ay may mga kilos na hindi ko maintindihan at magtatanong sa isang kasamahan bago ito hawakan." Pansinin na ang sagot na ito ay naglilimita sa pagbabago, pinoprotektahan muna ang kilos at binabanggit ang mga hindi alam.
Kung bakit ang bawat tugon ay maipagtatanggol o hindi kumpleto. Husgahan ang bawat isa batay sa naaprubahang pamantayan, hindi sa kagustuhan ng tagasuri. Ang unang pagtatangka ay maaaring isang makatwirang pangmatagalang direksyon ngunit hindi kumpleto bilang isang plano, dahil wala itong ebidensya ng napanatiling pag-uugali. Ang mas malakas na pagtatangka ay maliit, maaaring suriin, at tapat tungkol sa kawalan ng katiyakan.
5. Suriin ang kakayahan at planuhin ang paglipat
Ang ebidensya ng kakayahan ay ang pagganap sa isang bagong kaso ng legacy-code na hindi pa nakikita ng mag-aaral. Lagyan ng marka ang pagsusuri ng panganib at ang ebidensya na napanatili ang pag-uugali. Ang isang simpleng rubric ay gumagamit ng 0 hanggang 2 na iskala bawat pamantayan:
| Saligan | Napapansing ebidensya |
|---|---|
| Pagpapatupad ng gawain | Nagpaplano at nagpapatunay ng isang bounded legacy code improvement, at itinatala ang aksyon at ang ebidensya sa likod nito. |
| pangangatwiran | Ipinapaliwanag ang mga limitasyon, alternatibo, at kawalan ng katiyakan, at sinusuri ang mga panganib at ang ebidensya na napanatili ang pag-uugali. |
| Mga Hangganan | Gumagamit ng mga aprubadong pamamaraan, at humihingi ng tulong kapag ang impormasyon o awtoridad ay hindi sapat. |
Mga Anchor: 0 ay wala o hindi sinusuportahan, 1 ay bahagyang may mga kaugnay na kakulangan, at 2 ay kumpleto at makatwiran batay sa napagkasunduang pamantayan. Tukuyin nang hiwalay ang mga kritikal na error, tulad ng pagbabago ng pag-uugali nang walang pagsubok na makakapansin, kaya hindi maaaring itago ng isang pangkalahatang iskor ang isa. Ang rubric na ito ay isang panukala, hindi isang napatunayang pamantayan ng kahandaan: iakma ito kasama ang isang engineering manager at subukan ito. Ang aming gabay sa pagdidisenyo ng interaktibong pagsasanay na may kapaki-pakinabang na feedback nagpapakita kung paano sumulat ng feedback na nag-uugnay sa mga desisyon.
Planuhin nang sadya ang paglipat. Pagkatapos ng pagsasanay, bigyan ang bawat inhinyero ng isang maliit at totoong utang na loob na aayusin sa isang tagasuri, o magsagawa ng maikling pagbabalik-tanaw sa isang kamakailang pagbabago na nakasira sa isang bagay. Suriin ang paglipat pagkatapos ng angkop na karanasan sa totoong trabaho, hindi kaagad pagkatapos ng workshop.
Kung saan nakakatulong ang interactive na paghahatid
Nakakatulong ang mga interactive na format kung saan dapat mangako ang lahat bago nila makita ang grupo. Sa isang live na sesyon, maaaring magpakita ang isang facilitator ng isang maikling legacy snippet, hilingin sa bawat engineer na isumite ang unang pagbabagong gagawin nila at kung paano nila ito mapapatunayang ligtas, at pagkatapos ay ibunyag ang pagkalat bago ang talakayan. Ang parehong prompt ay maaaring tumakbo nang mag-isa para sa paghahanda. Sinusuportahan ng AhaSlides ang interactive na pag-aaral at paglipat sa pagitan ng live at self-paced na paghahatid. Ito ay isang tool sa presentasyon at pag-aaral, hindi isang lugar para patakbuhin o suriin ang code, kaya patakbuhin ang refactoring mismo sa iyong sariling kapaligiran. Suriin ang anumang partikular na function ng pag-author, feedback o pag-uulat na plano mong asahan laban sa iyong sariling daloy ng trabaho. Para sa gabay sa pagpili ng mga format, tingnan ang aming artikulo sa kailan gagamit ng adaptive, interactive, at live learning.
Sukatin kung ano ang nagbago
Magpasya nang maaga kung ano ang magpapakita na kayang gawin ng mga inhinyero ang gawain. Ihambing ang kalidad ng pagsusuri ng panganib at ang ebidensya ng napanatiling pag-uugali sa isang hindi pa nakikitang kaso, laban sa isang baseline. Tukuyin kung sino ang kasama, ang denominator at ang tiyempo. Kung bumuti ang mga resulta, suriin kung ano pa ang nagbago sa parehong panahon, tulad ng mga bagong kagamitan sa pagsubok, mas mabilis na pagbuo o pagbabago ng pagmamay-ari, bago i-kredito ang pagsasanay.
Mga limitasyon na maaaring manatili
- Oras para sa gawaing pagpapanatili. Kung hindi kailanman naka-iskedyul ang mga trabahong may kinalaman sa utang, wala pa ring lugar ang mga sinanay na inhinyero para magamit ang kasanayang ito.
- Pagsubok sa mga kagamitan. Kung walang magagamit na test harness o mabilis na pagkakagawa, mahirap magpatuloy sa maliliit na hakbang at madalas na pagsusuri.
- Saklaw ng kaso. Isang legacy case ang nagpapakita ng ilang uri ng panganib. Hindi inilalarawan ng score ang pangkalahatang paghatol ng isang inhinyero.
- Paghusga kung kailan hindi dapat i-refactor. Mas mainam na iwan na lang ang ilang code, palitan, o itigil na, at ang desisyong iyon ay higit pa sa kasanayan.
- Paglilipat. Ang pagganap sa isang kata ay hindi katulad ng pagganap sa isang production module sa ilalim ng delivery pressure.
Ipaalam ang mga ito sa mga sponsor nang maaga at magplano ng magkakahiwalay na pag-aayos. Ang pagsasanay ay nagpapabuti sa kung ano ang maaaring planuhin at patunayan ng isang inhinyero. Hindi ito lumilikha ng oras o kagamitan.
Mga madalas itanong
Ano ang isang proyekto sa pagsasanay sa refactoring?
Ito ay isang nakabalangkas na kasanayan sa legacy code kung saan ang mga inhinyero ay nagpaplano ng isang maliit na pagbabago, pinoprotektahan ang umiiral na pag-uugali gamit ang mga pagsubok, binabago ang disenyo sa maliliit na hakbang at ipinapakita na walang nasira.
Magandang paraan ba ang isang buong muling pagsulat upang matuto tungkol sa teknikal na utang?
Kadalasan hindi. Ang isang muling pagsusulat ay malaki, mahirap patunayan at itinatago ang kasanayang gusto mong malinang. Ang isang limitadong pagbabago na may mga pagsubok na kumukuha ng kasalukuyang pag-uugali ay nagpapakita ng pangangatwiran.
Paano mo masusuri kung ligtas na kayang mag-refactor ng mga inhinyero?
Magbigay ng bagong kaso ng legacy-code at bigyan ng marka ang pagsusuri ng panganib at ang ebidensya na ang pag-uugali ay napreserba laban sa napagkasunduang pamantayan. Ang isang pagsusulit sa mga pattern ng refactoring ay nagpapatunay lamang ng mga kinakailangan.
Kailangan mo ba ng sample codebase para sa training?
Kailangan mo ng lugar para ligtas na magsanay. Maraming koponan ang nagsisimula sa isang pampublikong kata at pagkatapos ay lumilipat sa isang limitadong bahagi ng kanilang sariling code. Dapat kumpirmahin ng iyong engineering manager na angkop ang code.
Saan magsisimula
Pumili ng isang maliit at paulit-ulit na uri ng legacy change sa iyong codebase. Isulat ang performance statement, ipa-validate sa isang engineering manager ang kaso at ang mga pagsubok na magpapakita ng napanatiling pag-uugali, at magbalangkas ng three-criterion rubric na may 0 hanggang 2 scale at isang listahan ng mga kritikal na error. Subukan ito kasama ang isang maliit na grupo bago mo ito ilunsad.
Para makita kung paano maaaring gumana nang live ang isang refactoring decision exercise kasama ang sarili mong team, at magamit muli nang mag-isa pagkatapos, tuklasin ang AhaSlides.
