Ako dobyť pôvodný kód

V určitom okamihu vašej kariéry vývojárov vám šéf odovzdá kúsok starého kódu - kód, ktorý už dávno napísal niekto iný. Váš nadriadený vám povie, aby ste sa tento starší kód naučili, opravili a pridali doň nové funkcie.

V posledných dvoch desaťročiach som bol v tejto situácii mnohokrát. Môžem pomôcť.

Ako porozumieť starému kódu

Ak budete mať šťastie, budete mať k dispozícii dokumentáciu alebo aspoň priame komentáre. Možno jeden alebo dvaja pôvodní autori budú ešte stále nablízku, aby pomohli. Ale väčšinou také šťastie mať nebudeš.

Poďme sa baviť o tom, čo budete robiť v tých nešťastných prípadoch.

Najprv musíte byť pokorní. Rešpektujte kód a vývojárov, ktorí ho napísali.

Je ľahké pozrieť sa na prácu, ktorá prišla pred vami, a rozhodnúť sa, že to nie je dobré a že môžete robiť lepšie. Toto je nesprávny postoj. Bude vás viesť veľmi nebezpečnou cestou.

Ak pôjdete touto nebezpečnou cestou, začnete robiť zmeny skôr, ako správne pochopíte ich dopad. „Opravíte“ veci, ktoré nie sú pokazené, pretože sú napísané štýlom, ktorý sa vám nepáči, alebo sú založené na staršom spôsobe konania. S týmto prístupom nakoniec stratíte neskutočne veľa času.

Tak prestaň. Urobte krok späť a uvedomte si, že všetko v tej kódovej základni sa stalo určitým spôsobom z nejakého dôvodu.

Pokiaľ nepoznáte kód vpred a vzad, musíte predpokladať, že boli dobré dôvody na to, aby bol napísaný tak, ako je, a že ste ich ešte nezistili.

Toto je oveľa produktívnejší prístup a ušetrí vám to od rozbitia všetkého, potom už len budete chcieť vyskočiť z okna, keď ho nemôžete dať dostatočne rýchlo späť.

Nepoužívajte Humpty Dumpty svoju základňu kódov.

Najlepší spôsob, ako som sa naučil naučiť sa databázu kódov, je začať na úrovni používateľského rozhrania a potom sa vrátiť späť do kódu.

Vyberte tok jedného používateľa, napríklad prihlásenie, zadanie objednávky, napísanie recenzie alebo čokoľvek, čo je relevantné pre vašu konkrétnu aplikáciu. Prejdite procesom ako koncový používateľ. Potom sa pozrite na kód, počnúc kódom používateľského rozhrania - mal by byť najľahšie rozpoznateľný - a postupujte každý krok dozadu až do databázy.

Postupne nakreslite sekvenčný diagram, ktorý ilustruje, čo sa deje. Ak si nie ste istí, čo je to sekvenčný diagram alebo ako ho nakresliť, pozrite si tento bezplatný návod. Ak nemáte dobrý nástroj na kreslenie UML, je tu jeden bezplatný.

Po dokončení prvého sekvenčného diagramu začnite pomocou lokálnej kópie základne kódov, ktorú môžete ľahko obnoviť, vykonať jemné zmeny v niektorých komponentoch, s ktorými ste sa stretli. Zistite, či dokážete predpovedať účinky svojich zmien na aplikáciu. Toto je dobrý spôsob, ako vyskúšať svoje porozumenie.

Tento postup neustále opakujte a dopĺňajte svoje diagramy, až kým nebudete mať úplný obraz o celej aplikácii (alebo aspoň o všetkých častiach, za ktoré ste zodpovední).

Ak chcete získať bonusové body, nezabudnite zdieľať svoje poznámky a diagramy. Umiestnite ich na dobre viditeľné miesto, kde ich môže ľahko nájsť ďalší vývojár, ktorý príde. Nerobte si starosti s tým, či sú dokonalé alebo dokonca pekné. Rob len to, čo môžeš. Každá troška pomáha.

Celkovo je najdôležitejšie byť trpezlivý a vyhýbať sa bitiu. Kódex je zložitá vec. Porozumenie starému kódu vyžaduje čas. Zostaň v kľude.

Ako opraviť starší kód

Najväčšou výzvou, ktorej budete čeliť pri opravovaní pôvodného kódu, je rozhodnutie, ako ďaleko s opravou zájdete. Dôrazne vám odporúčam najskôr vykonať minimálnu uskutočniteľnú zmenu . To znamená, že by ste mali urobiť najmenej rušivú zmenu, ktorá problém úplne vyrieši, skôr ako sa pokúsite vyčistiť a refaktorovať akýkoľvek kód.

Získate tak únikový poklop. Horší scenár, ak sa dostanete preč, aby ste sa zamerali na inú prioritu - alebo ak ste v krátkom termíne -, prinajmenšom budete mať dokopy nejaký pracovný kód, na ktorý sa môžete vrátiť.

Ak váš kód začne fungovať, ak vám ešte zostáva čas, môžete začať robiť malé, postupné vylepšenia.

Martin Fowler zostavil katalóg refaktoringov, ktoré vám poskytnú dobrú predstavu o typoch zmien, ktoré môžete vykonať na postupné vylepšenie kódovej základne. Skontrolujte to tu. Cieľom je ponechať kód vždy v lepšom stave, ako bol, keď ste ho našli.

Niekedy sa stretnete s chybou, ktorá je v skutočnosti dôsledkom štrukturálnej chyby. Tieto chyby nie je možné opraviť jednoduchou zmenou podmienenej logiky. Vyžadujú invazívnejšie zmeny.

To je miesto, kde sa veci chlpatia. Musíte byť k sebe brutálne úprimní, čo je minimálna životaschopná zmena. Každé vlákno vašej bytosti bude chcieť rozobrať kód od seba a celú vec prepísať znova. Nerob to!

Držte sa rýchlej opravy, po ktorej nasleduje prírastkové vylepšenie, ktoré ju refaktoruje a vyčistí podľa možností. Vaším cieľom je iba zakaždým vylepšiť kód. Čím dlhšie budete udržiavať databázu kódov, tým lepšie to bude.

Ak chcete, aby tento prístup skutočne fungoval, uistite sa, že ste vždy vyplnili svoje odhady, aby ste mali čas na trochu refaktoringu.

Niekedy sú štrukturálne chyby také zlé, že stratégia neustáleho opravovania jednoducho nebude fungovať. Táto situácia je v skutočnosti oveľa zriedkavejšia, ako by ste si mysleli.

Opäť musíte byť k sebe brutálne úprimní, pokiaľ ide o náklady / prínos prepísania alebo redizajnu. Musíte akceptovať, že v konečnom dôsledku pôjde o obchodné a nie technické rozhodnutie.

Pripravte sa na uvedenie vášho prípadu z obchodných podmienok. Čo bude potrebné na zásadnú reštrukturalizáciu kódexu? Aké sú skutočné obchodné riziká toho, že tak neurobíte? Ak máte pevné puzdro, budete nakoniec vypočutí. Nebuďte však prekvapení, že najskôr to bude trvať ešte niekoľko cyklov opráv.

Pamätajte: ak robíte zásadné opravy, najskôr sa uistite, či je podpora pre danú zmenu a či je k dispozícii primeraný rozpočet. Týmto sa neskúšajte lietať pod radarom. Pokiaľ, samozrejme, nemáte radi nepríjemné rozhovory s vedením, keď začnete porušovať veci a chýbať termíny.

Ako pridať nové funkcie k starému kódu

Nakoniec budete vyzvaní k pridaniu funkcií k starému kódu. V tomto okamihu musíte urobiť dôležité rozhodnutie. „Pôjdete s prúdom“ súčasnej kódovej základne alebo sa vydáte novým smerom?

Opäť vám odporúčam, aby ste boli pri hodnotení brutálne čestní. Zhoršilo by to ďalšie sledovanie vzorcov a postupov zrejmých z existujúcej základne kódov alebo by sa hromadilo k existujúcemu problému?

Väčšinou budete chcieť mať veci stabilné. Stačí postupne pridávať pomocou existujúcich vzorcov a postupov kódu. Znovu použite existujúce prvky. Vykonajte čo najmenej rušivé zmeny a zároveň urobte malé, prírastkové vylepšenia čistením a refaktoringom.

Ak si myslíte, že je nevyhnutne potrebný nový smer, budete musieť nájsť spôsob, ako izolovať vaše zmeny a čo najvoľnejšie ich spojiť s existujúcou databázou kódov.

Skúste si novú funkciu vyčleniť ako samostatný projekt. Potom môžete vystaviť rozhranie API, ktoré umožňuje pripojiť starší kód k vášmu novému kódu. Vďaka tomu váš nový kód a starý starší kód nemusia navzájom veľa vedieť.

Začína to byť trochu zložité, keď potrebujete na implementáciu novej funkcie použiť funkcie zo starého kódu. Najlepším spôsobom, ako izolovať starý kód od nového, je použiť vzor adaptéra.

DO Factory má dobré vysvetlenie vzoru adaptéra:

„Vzor adaptéra prekladá jedno rozhranie (vlastnosti a metódy objektu) do druhého. Adaptéry umožňujú programovacím komponentom spolupracovať, čo by inak nebolo možné kvôli nesprávnym rozhraniam. Vzor adaptéra sa tiež označuje ako vzor obaľovača. Jedným scenárom, v ktorom sa adaptéry bežne používajú, je prípad, keď je potrebné integrovať nové komponenty a spolupracovať s existujúcimi komponentmi v aplikácii. Ďalším scenárom je refaktoring, v ktorom sú časti programu prepisované vylepšené rozhranie, ale starý kód stále očakáva pôvodné rozhranie. “

Tu je niekoľko odkazov na vysvetlenia a príklady v rôznych jazykoch.

  • Príklad vzoru adaptéra v jazyku JavaScript
  • C # príklad adaptéra
  • Java vzor adaptéra

Kľúčové jedlá

V súhrne uvádzame kľúčové body, ktoré vám pomôžu vyriešiť a nakoniec zvíťaziť nad každou kódovou základňou:

  1. Nikdy neposudzujte pôvodný kód ani ho nemeňte, kým si neurobíte čas na jeho úplné pochopenie.
  2. Sekvenčné diagramy sú váš priateľ.
  3. Uprednostňujte malé, postupné vylepšenia pred veľkoobchodnými prepismi alebo zmenami.
  4. Každá zmena by sa mala pokúsiť zanechať kód o niečo lepší, ako bol, keď ste ho našli.
  5. Ak potrebujete urobiť veľké zmeny, urobte obchodný prípad a najskôr získajte súhlas.
  6. Pri pridávaní nových funkcií skúste „ísť s tým“.
  7. Ak potrebujete vziať kód novým smerom, izolovajte zmeny a na integráciu použite vzor adaptéra.

Dúfam, že vám bol tento článok užitočný. Mojou misiou je pomáhať čo najväčšiemu počtu vývojárov. Story Odporúčajte ❤ tento príbeh pomocou zeleného srdca nižšie, ktoré vám pomôže šíriť informácie.

Chcete lepšie kódovať? Pridajte sa k tisícom vývojárov, ktorí odo mňa každý týždeň zadarmo dostávajú hodnotné články a informácie, ako je táto . Stačí kliknúť sem.