Refaktor vo veľkom meradle: Prečo by ste niekedy niečo také robili?

Ak to nie je zlomené, neopravujte to.

Je to dobre známa fráza, ale ako vieme, najväčší ľudský technologický pokrok dosiahli ľudia, ktorí sa rozhodli napraviť to, čo nie je porušené. Najmä v softvérovom priemysle by sa dalo tvrdiť, že väčšina z toho, čo robíme, je oprava toho, čo nie je pokazené.

Oprava funkčnosti, zlepšenie používateľského rozhrania, zvýšenie rýchlosti a efektívnosti pamäte, pridanie funkcií: všetko sú to činnosti, pri ktorých je ľahké zistiť, či sa im oplatí robiť, a potom my ako skúsení vývojári Rails argumentujú za alebo proti tráveniu nášho času nad nimi. Existuje však činnosť, ktorá väčšinou spadá do šedej zóny - štandardné refaktorovanie , a najmä rozsiahle refaktorovanie kódu.

Pojem refaktoring vo veľkom meradle si zaslúži vysvetlenie. Presne to, čo možno považovať za „rozsiahle“, sa bude líšiť od prípadu k prípadu, pretože tento výraz je trochu neurčitý, ale považujem čokoľvek, čo významne ovplyvňuje viac ako iba niekoľko tried alebo viac ako jeden podsystém, a jeho rozhranie za „veľký“ . “ Na druhej strane, akýkoľvek refaktoring Rails, ktorý zostane skrytý za rozhraním jednej triedy, by bol určite „malý“. Samozrejme, medzi nimi je veľa šedej zóny. Na záver dôverujte svojim vnútornostiam, ak sa toho bojíte, potom sú pravdepodobne „veľké“.

Refaktoring podľa definície neprináša žiadne viditeľné funkcie, nič, čo by ste mohli klientovi zobraziť, žiadne výsledky. V najlepšom prípade by mohli vyprodukovať malé vylepšenia rýchlosti a využitia pamäte, ale to nie je primárnym cieľom. Dalo by sa povedať, že primárnym cieľom je kód, s ktorým ste spokojní. Ale pretože preskupujete kód takým spôsobom, že to bude mať ďalekosiahle následky v celej kódovej základni, je pravdepodobné, že sa rozpúta všetko peklo a budú problémy. Odtiaľ samozrejme pochádza aj hrôza, ktorú sme spomenuli. Už ste niekedy predstavili niekoho nového vo svojej kódovej základni a potom, čo sa spýtali na kúsok zvláštne usporiadaného kódu, odpovedali ste niečím v tomto duchu:

Áno, toto je starý kód, ktorý mal v tom čase zmysel, ale zmenili sa špecifikácie a jeho oprava je teraz príliš drahá?

Možno ste im venovali veľmi vážny pohľad a povedali ste im, aby to nechali tak a nedotýkajte sa toho.

Otázka: „Prečo by sme to vôbec chceli robiť?“ je prirodzený a môže byť rovnako dôležitý ako to ...

Otázka: „Prečo by sme to vôbec chceli robiť?“ je prirodzený proces a môže byť rovnako dôležitý ako proces refaktoringu, pretože často existujú ľudia, ktorých musíte presvedčiť, aby vám umožnili stráviť drahý čas refaktorovaním. Uvažujme teda o prípadoch, kedy by ste to chceli urobiť, a o výhodách, ktoré je potrebné získať:

Vylepšenia výkonu

Ste spokojní so súčasnou organizáciou vášho kódu od bodu údržby, ale stále spôsobuje problémy s výkonom. Je príliš ťažké optimalizovať spôsob, akým je momentálne nastavený, a zmeny by boli veľmi krehké.

Tu je potrebné urobiť iba jednu vec a to je rozsiahly profil. Spustite referenčné hodnoty a urobte odhady, koľko získate, a potom skúste odhadnúť, ako sa to premení na konkrétne zisky. Niekedy si možno uvedomíte, že navrhované refaktorovanie kódu sa neoplatí. Inokedy budete mať chladné tvrdé dáta, aby ste podporili prípad.

Architektonické vylepšenia

Možno je architektúra v poriadku, ale trochu zastaraná, alebo je možno také zlé, že sa krčíte zakaždým, keď sa dotknete tejto časti kódovej základne. Funguje to dobre a rýchlo, ale je ťažké pridať nové funkcie. V tejto bolesti spočíva obchodná hodnota refaktoringu. „Bolesť“ tiež znamená, že procesu refaktoringu bude pridávanie nových funkcií trvať dlhšie, možno oveľa dlhšie.

A je potrebné získať výhodu. Vykonajte odhady nákladov a prínosov pre niekoľko vzorových funkcií s navrhovaným veľkým refaktoringom alebo bez neho. Vysvetlite, že podobné rozdiely sa budú vzťahovať na väčšinu nadchádzajúcich funkcií, ktoré sa dotknú tejto časti systému teraz a navždy v budúcnosti, zatiaľ čo sa systém bude vyvíjať. Vaše odhady môžu byť nesprávne, pretože sa často vyskytujú pri vývoji softvéru, ale ich pomery budú pravdepodobne v správnom poradí.

Aktualizácia

Kód je niekedy spočiatku dobre napísaný. Ste s tým nesmierne spokojní. Je rýchly, pamäťovo efektívny, udržiavateľný a dobre zosúladený so špecifikáciami. Spočiatku. Potom sa však zmenia špecifikácie, obchodné ciele sa posunú alebo sa dozviete niečo nové o svojich koncových používateľoch, čo zneplatní vaše pôvodné predpoklady. Tento kód stále funguje dobre a stále sa z neho veľmi tešíte, ale keď sa na to pozriete v kontexte konečného produktu, je niečo jednoducho nepríjemné. Veci sú umiestnené na mierne nesprávnom subsystéme alebo vlastnosti sedia v nesprávnej triede, alebo možno niektoré názvy už nemajú zmysel. Teraz plnia úlohu, ktorá je z obchodného hľadiska pomenovaná úplne inak. Stále je však veľmi ťažké ospravedlniť akýkoľvek druh rozsiahleho refaktoringu Rails, pretože práca bude prebiehať v rozsahu s ktorýmkoľvek z ďalších príkladov, ale výhody sú oveľa menej hmatateľné. Keď sa nad tým zamyslíte, nie je ani také ťažké ho udržiavať. Musíte si len uvedomiť, že niektoré veci sú v skutočnosti niečo iné. Musíte si len uvedomiť, že A skutočne znamená B a vlastnosť Y na A sa skutočne týka C.

A tu spočíva skutočný prínos. V oblasti neuropsychológie existuje veľa experimentov, ktoré naznačujú, že naša krátkodobá alebo pracovná pamäť je schopná pojať iba 7 +/- 2 prvkov, z ktorých jeden je Sternbergov experiment . Keď študujeme predmet, začneme základnými prvkami a spočiatku, keď uvažujeme o koncepciách na vyššej úrovni, musíme premýšľať o ich definíciách. Zvážte napríklad jednoduchý výraz „solené heslo SHA256“. Spočiatku musíme vo svojej pracovnej pamäti obsahovať definície pojmov „solené“ a „SHA256“ a možno aj definíciu „hash funkcie“. Ale akonáhle tento pojem úplne pochopíme, zaberá iba jeden pamäťový slot, pretože mu rozumieme intuitívne. To je jeden z dôvodov, prečo musíme úplne porozumieť konceptom na nižšej úrovni, aby sme dokázali uvažovať o koncepciách na vyššej úrovni. To isté platí pre pojmy a definície špecifické pre náš projekt. Ak si však musíme pamätať na preklad do skutočného významu zakaždým, keď diskutujeme o našom kóde, tento preklad zaberá ďalší z tých vzácnych slotov pracovnej pamäte. Produkuje kognitívne zaťaženie a sťažuje logiku v logike v našom kóde. Ak to potom bude ťažšie zdôvodniť, znamená to, že existuje väčšia šanca, že prehliadneme dôležitý bod a predstavíme chybu.

A nezabúdajme na zjavnejšie vedľajšie účinky. Pri diskusiách o zmenách s našim klientom alebo s kýmkoľvek, kto vie len o správnych obchodných podmienkach, existuje veľká pravdepodobnosť zámeny. Noví ľudia, ktorí sa pridajú k tímu, sa musia oboznámiť s obchodnou terminológiou aj s jej náprotivkami v kóde.

Myslím si, že tieto dôvody sú veľmi presvedčivé a v mnohých prípadoch oprávňujú náklady na refaktorovanie. Napriek tomu buďte opatrní, môže existovať veľa okrajových prípadov, keď budete musieť podľa svojho najlepšieho úsudku určiť, kedy a ako sa má refaktorovať.

Nakoniec, rozsiahle refaktorovanie je dobré z rovnakých dôvodov, prečo mnohých z nás teší zahájenie nového projektu. Pozeráte sa na ten prázdny zdrojový súbor a vašou mysľou začne víriť odvážny nový svet. Tentokrát to urobíte správne, kód bude elegantný, bude krásne vyskladaný, rýchly, robustný a ľahko rozšíriteľný a čo je najdôležitejšie, bude s ním radosť pracovať každý deň. Refaktoring v malom i veľkom rozsahu vám umožní znovu získať ten pocit, vdýchnuť nový život starej kódovej základni a splatiť tento technický dlh.

Nakoniec je najlepšie, ak sa refaktoring riadi plánmi, ktoré uľahčujú implementáciu určitej novej funkcie. V takom prípade bude refaktoring viac zameraný a veľa času stráveného refaktoringom sa tiež získa späť späť okamžite rýchlejšou implementáciou samotnej funkcie.

Príprava

Uistite sa, že pokrytie testu je veľmi dobré vo všetkých oblastiach kódovej základne, ktorých sa pravdepodobne dotknete. Ak vidíte určité časti, ktoré nie sú dobre zakryté, najskôr venujte nejaký čas vylepšeniu testovacieho pokrytia. Ak testy vôbec nemáte, mali by ste ich najskôr stráviť časom. Ak nemôžete vytvoriť správny testovací balík, sústreďte sa na akceptačné testy a napíšte ich toľko, koľko môžete, a počas refaktorovania nezabudnite napísať jednotkové testy. Teoreticky môžete vykonať refaktoring kódu bez dobrého pokrytia testom, ale bude to vyžadovať, aby ste robili veľa manuálnych testov a robili to často. Bude to trvať oveľa dlhšie a bude náchylnejšie na chyby. V konečnom dôsledku, ak pokrytie testom nie je dosť dobré, náklady na vykonanie rozsiahleho refaktoringu Rails môžu byť také vysoké, že by ste, bohužiaľ, mali uvažovať o tom, že tak neurobíte vôbec. Podľa môjho názoru je to výhoda automatizovaných testov, ktorá nie je dostatočne často zdôrazňovaná. Automatizované testy vám umožňujú refaktorovať často a čo je dôležitejšie, byť v tom odvážnejší.

Keď sa ubezpečíte, že pokrytie testom je dobré, je čas začať mapovať svoje zmeny. Spočiatku by ste nemali robiť žiadne programovanie. Musíte zhruba zmapovať všetky súvisiace zmeny a vysledovať všetky dôsledky prostredníctvom kódovej základne, ako aj načítať si o nich vedomosti. Vaším cieľom je presne pochopiť, prečo niečo meníte, a úlohu, ktorú hrá v kódovej základni. Ak narazíte na to, že veci sa menia, len preto, že vyzerajú tak, že je potrebné ich zmeniť, alebo preto, že sa niečo zlomilo a zdá sa, že to napraví, pravdepodobne skončíte v mŕtvej uličke. Zdá sa, že nový kód funguje, ale nesprávne, a teraz si už ani nepamätáte všetky vykonané zmeny. V tomto okamihu bude pravdepodobne potrebné opustiť prácu, ktorú ste vykonali pri rozsiahlom refaktoringu kódu, a v podstate ste stratili čas. Urobte si preto čas a preskúmajte kód, aby ste pochopili dôsledky každej zmeny, ktorú sa chystáte vykonať. Nakoniec to zaplatí pekne.

Budete potrebovať pomoc pre proces refaktoringu. Môžete dať prednosť niečomu inému, ale páči sa mi jednoduchý kúsok čistého papiera a pero. Začnem napísaním počiatočnej zmeny, ktorú chcem vykonať, v ľavom hornom rohu článku. Potom začnem hľadať všetky miesta, ktorých sa zmena dotkla, a zapíšem si ich pod úvodnú zmenu. Tu je dôležité použiť váš úsudok. Poznámky a diagramy na papieri sú tu nakoniec pre vás, takže si vyberte štýl, ktorý najlepšie vyhovuje vašej pamäti. Píšem krátke úryvky kódu so značkami bodiek pod nimi a veľa šípok vedúcich k ďalším takýmto poznámkam, ktoré označujú veci, ktoré na ňom priamo závisia (plná šípka) alebo nepriamo (prerušované šípky). Šípky tiež komentujem skratkovými značkami ako pripomienku nejakej konkrétnej veci, ktorú som si všimol v databáze kódov. Pamätajte, že k týmto poznámkam sa budete vracať až v priebehu najbližších dní, kým budete vykonávať zmeny, ktoré sú v nich naplánované, a je úplne v poriadku používať veľmi krátke a záhadné pripomienky, aby zaberali menej miesta a dali sa ľahšie rozložiť na papier . Párkrát som čistil stôl mesiace po refaktoringu Rails a našiel som jeden z tých papierov. Bol to úplný blázon, vôbec som netušil, čo čo na tom papieri znamená, až na to, že to mohol vypísať niekto zo šialenstva. Ale viem, že ten kúsok papiera bol pri práci na probléme nevyhnutný. Tiež si nemyslite, že musíte vypísať každú jednu zmenu. Môžete ich zoskupiť a sledovať podrobnosti iným spôsobom. Napríklad na vašom hlavnom príspevku si môžete všimnúť, že musíte „premenovať všetky výskyty A.b na C.d“ a potom môžete sledovať špecifiká niekoľkými rôznymi spôsobmi. Môžete ich všetky napísať na samostatný kúsok papiera, môžete naplánovať, že ešte raz vykonáte globálne vyhľadávanie všetkých jej výskytov, alebo môžete jednoducho nechať všetky zdrojové súbory, v ktorých je potrebné vykonať zmenu, otvoriť vo svojom voľnom editore. a urobte si mentálnu poznámku, aby ste sa po nich vrátili späť, akonáhle dokončíte mapovanie zmien.

Keď zmapujete dôsledky svojej počiatočnej zmeny, bude to s najväčšou pravdepodobnosťou identifikovať ďalšie zmeny, ktoré majú samotné ďalšie dôsledky. Zopakujte analýzu aj pre nich a zaznamenajte všetky závislé zmeny. V závislosti od veľkosti zmien ich môžete napísať na rovnaký kúsok papiera alebo zvoliť nový prázdny. Pri mapovaní zmien je veľmi dôležité vyskúšať sa a pokúsiť sa určiť hranice, kde môžete skutočne vetviace zmeny zastaviť. Chcete obmedziť refaktoring na najmenšiu rozumnú, zaoblenú množinu zmien. Ak uvidíte bod, v ktorom sa môžete jednoducho zastaviť a nechať zvyšok taký, aký je, urobte tak aj v prípade, že by mal byť upravený, aj keď to koncepčne súvisí s vašimi ďalšími zmenami. Dokončite toto kolo refaktoringu kódu, dôkladne otestujte, nasaďte a vráťte sa pre ďalšie. Tieto body by ste mali aktívne hľadať, aby bola veľkosť zmien zvládnuteľná. Samozrejme, ako vždy, zavolajte na súd. Pomerne často som dospel k bodu, keď som mohol prerušiť proces refaktoringu pridaním niektorých tried proxy, aby som urobil trochu prekladu rozhrania. Začal som ich dokonca implementovať, keď som si uvedomil, že budú mať toľko práce, že posunú refaktoring o kúsok ďalej do bodu, kde bude bod „prirodzeného zastavenia“ (t. J. Takmer nie je potrebný žiadny proxy kód). Potom som cúval dozadu, vrátil svoje posledné zmeny a znova vykonal opravu. Ak to všetko znie trochu ako mapovanie nezmapovaného územia, je to preto, lebo sa na to cítim, ibaže územné mapy sú iba dvojrozmerné.

Exekúcia

Po dokončení prípravy refaktoringu je čas vykonať plán. Uistite sa, že je vaša koncentrácia hore a zabezpečte prostredie bez vyrušovania. V tomto bode niekedy zájdem až k úplnému otočeniu internetového pripojenia. Ide o to, že ak ste sa dobre pripravili, pripravte si dobrý papier na poznámky vedľa seba a vaša koncentrácia je hore! Týmto spôsobom sa často môžete pohybovať veľmi rýchlo. Teoreticky bola väčšina práce vykonaná vopred, počas prípravy.

Akonáhle skutočne refactorujete kód, venujte pozornosť zvláštnym kúskom kódu, ktoré robia niečo veľmi konkrétne a môžu sa javiť ako zlý kód. Možno sú to zlý kód, ale pomerne často skutočne riešia zvláštny rohový prípad, ktorý bol objavený pri vyšetrovaní chyby vo výrobe. V priebehu času väčšina kódu Rails narastie „do chĺpkov“ alebo „bradavíc“, ktoré narábajú s podivnými chybami v rohových prípadoch, napríklad s podivným kódom odpovede, ktorý je tu pravdepodobne potrebný pre IE6, alebo s podmienkou, ktorá zvláda zvláštnu chybu načasovania. Nie sú dôležité pre celkový obraz, sú to stále významné detaily. V ideálnom prípade sú výslovne pokryté jednotkovými testami, pokiaľ sa ich nepokúšate najskôr pokryť. Raz som mal za úlohu preniesť stredne veľkú aplikáciu z Rails 2 na Rails 3. Kód som veľmi dobre poznal, ale bol trochu chaotický a bolo treba zohľadniť veľa zmien, takže som sa rozhodol pre opätovnú implementáciu. V skutočnosti to nebola skutočná opätovná implementácia, pretože to nikdy nie je chytrý krok, ale začal som s prázdnou aplikáciou Rails 3 a zrefaktoroval som vertikálne plátky starej aplikácie do novej, zhruba s využitím opísaného postupu. Zakaždým, keď som dokončil vertikálny plátok, prešiel som starým kódom Rails, pozrel som sa na každý riadok a dvakrát skontroloval, či má v novom kóde svoj náprotivok. V podstate som vybral všetky staré kódy „vlasov“ a replikoval ich v novej kódovej základni. Nakoniec nová základňa kódov vyriešila všetky rohové prípady.

Uistite sa, že ručné testovanie vykonávate dostatočne často. Obaja vás prinútia hľadať prirodzené „zlomy“ v procese refaktoringu, ktoré vám umožnia otestovať časť systému a dodajú vám istotu, že ste neporušil nič, čo ste nečakali preraziť v procese.

Zabaliť

Po dokončení opätovnej úpravy kódu Rails nezabudnite skontrolovať všetky zmeny ešte raz. Pozri sa na celý rozdiel a choď cez to. Pomerne často si všimnete jemné veci, ktoré ste zmeškali na začiatku refaktoringu, pretože ste nemali vedomosti, ktoré teraz máte. Je to príjemná výhoda rozsiahleho refaktoringu: získate jasnejší mentálny obraz o organizácii kódu, najmä ak ste ho pôvodne nenapísali.

Ak je to možné, požiadajte o preskúmanie aj kolegu. Nemusí byť ani zvlášť oboznámený s presnou časťou kódovej základne, ale mal by byť všeobecne oboznámený s projektom a jeho kódom. Nový pohľad na zmeny môže veľa pomôcť. Ak absolútne nemôžete dosiahnuť, aby sa na nich pozrel iný vývojár, musíte sa vydať za samotného vývojára. Doprajte si dobrý spánok a skontrolujte to s čerstvou mysľou.

Ak vám chýba QA, budete musieť nosiť aj tento klobúk. Opäť si urobte prestávku a od kódu sa vzdiaľte, potom sa vráťte a vykonajte manuálne testovanie. Práve ste podstúpili ekvivalent toho, že ste vošli do preplnenej elektrickej rozvodnej skrinky s hromadou nástrojov a všetko ste to roztriedili, prípadne vyrezali a znova zapojili, takže je treba venovať trochu viac starostlivosti ako obvykle.

Na záver si užite plody vašej práce a zvážte všetky plánované zmeny, ktoré budú teraz oveľa čistejšie a ľahšie implementovateľné.

Kedy by ste to neurobili?

Aj keď má pravidelné vykonávanie veľkého rozsahu refaktoring mnoho výhod, aby bol kód projektu svieži a kvalitný, stále je to veľmi nákladná operácia. Existujú aj prípady, keď by to nebolo vhodné:

Vaše testovacie pokrytie je zlé

Ako už bolo spomenuté: veľmi zlé pokrytie testom môže byť veľkým problémom. Použite svoj vlastný úsudok, ale v krátkodobom horizonte by mohlo byť lepšie zamerať sa na zvýšenie pokrytia pri práci na nových funkciách a vykonaní čo najväčšieho množstva lokalizovaných malých refaktorov. To vám veľmi pomôže, keď sa rozhodnete prelomiť a triediť väčšie časti kódovej základne.

Refaktoring nie je riadený novou funkciou a základňa kódov sa dlho nezmenila

Použil som minulý čas namiesto toho, aby som úmyselne povedal: „základňa kódov sa nezmení“. Súdiac podľa skúseností (a skúsenosťami myslím, že sa mnohokrát mýlili), takmer nikdy sa nemôžete spoliehať na svoje predpovede, kedy bude potrebné zmeniť určitú časť kódovej základne. Urobte teda ďalšiu najlepšiu vec: pozerajte sa do minulosti a predpokladajte, že sa minulosť bude opakovať. Ak sa niečo dlho nezmenilo, pravdepodobne to teraz nemusíte meniť. Počkajte, kým táto zmena príde a budete pracovať na niečom inom.

Ste stlačený na čas

Údržba je najdrahšia časť v životnom cykle projektu a vďaka refaktoringu je to lacnejšie. Je absolútne nevyhnutné, aby akýkoľvek podnik použil refaktoring na zníženie technického dlhu, aby zlacnel budúcu údržbu. V opačnom prípade hrozí nebezpečenstvo vstupu do začarovaného kruhu, v ktorom je pridávanie nových funkcií čoraz nákladnejšie. Dúfam, že je zrejmé, prečo je to zlé.

To znamená, že rozsiahle refaktorovanie je veľmi, veľmi nepredvídateľné, pokiaľ ide o to, ako dlho to bude trvať, a nemali by ste to robiť na polceste. Ak z akýchkoľvek vnútorných alebo vonkajších dôvodov na vás tlačí čas a nie ste si istí, že v tomto časovom rámci budete schopní dokončiť, možno budete musieť upustiť od refaktoringu. Tlak a stres, najmä časovo indukovaný typ, vedú k nižšej úrovni koncentrácie, ktorá je nevyhnutne nevyhnutná pre rozsiahle refaktorovanie. Pracujte na získaní väčšieho množstva „nákupu“ od svojho tímu, vyčleňte si na to čas a nahliadnite do svojho kalendára na obdobie, keď budete mať čas. Nie je potrebné, aby to bol nepretržitý časový úsek. Samozrejme, budete musieť vyriešiť ďalšie problémy, ale tieto prestávky by nemali byť dlhšie ako deň alebo dva. Ak je to tak, budete si musieť pripomenúť svoj vlastný plán, pretože začnete zabúdať na to, čo ste sa dozvedeli o databáze kódov, a presne na tom mieste, kde ste sa zastavili.

Záver

Dúfam, že som vám dal niekoľko užitočných pokynov a presvedčil vás o výhodách vykonávania rozsiahleho refaktoringu pri určitých príležitostiach a dovolím si povedať, že je to nevyhnutnosť. Téma je veľmi vágna a samozrejme tu nie je nič povedané, jednoznačná pravda a podrobnosti sa budú pri jednotlivých projektoch líšiť. Snažil som sa poskytnúť radu, ktorá je podľa môjho názoru všeobecne použiteľná, ale ako vždy, zvážte váš konkrétny prípad a využite svoje vlastné skúsenosti na prispôsobenie sa jeho konkrétnym výzvam. Veľa šťastia pri refaktoringu!