Sådan erobrer du ældre kode

På et eller andet tidspunkt i din udviklerkarriere vil din chef give dig et stykke ældre kode - kode, som en anden skrev for længe siden. Din chef vil fortælle dig at lære denne ældre kode, rette den og tilføje nye funktioner til den.

Jeg har været i denne situation mange gange i løbet af de sidste to årtier. Jeg kan hjælpe.

Sådan forstås ældre kode

Hvis du er heldig, har du dokumentation eller i det mindste in-line kommentarer. Måske vil en eller to af de originale forfattere stadig være til stede for at hjælpe. Men det meste af tiden vil du ikke være så heldig.

Lad os tale om, hvad du vil gøre i de uheldige tilfælde.

Først skal du være ydmyg. Respekter koden og udviklerne, der skrev den.

Det er let at se på arbejde, der kom foran dig og beslutte, at det ikke er godt, og at du kan gøre det bedre. Dette er den forkerte holdning. Det fører dig ned ad en meget farlig sti.

Hvis du går ned ad denne farlige vej, begynder du at foretage ændringer, før du korrekt forstår virkningen af ​​disse ændringer. Du “ordner” ting, der ikke er ødelagte, fordi de er skrevet i en stil, som du ikke kan lide, eller er baseret på en ældre måde at gøre tingene på. I sidste ende spilder du utrolig meget tid med denne holdning.

Så stop. Tag et skridt tilbage og indse, at alt i kodebasen blev gjort på en bestemt måde af en grund.

Indtil du kender koden frem og tilbage, skal du antage, at der var gode grunde til, at den skulle skrives, som den er, og at du bare ikke har fundet ud af dem endnu.

Dette er en meget mere produktiv holdning, og det vil spare dig for at bryde alt, og så bare ønske at springe ud af et vindue, når du ikke hurtigt kan sætte det sammen igen.

Humpty Don't Dumpty din codebase.

Den bedste måde, jeg har fundet ud af at lære en codebase, er at starte på brugergrænsefladeniveau og derefter arbejde mig tilbage i koden.

Vælg et enkelt brugerflow, som at logge ind, placere en ordre, skrive en anmeldelse eller hvad der er relevant for din særlige applikation. Gå gennem strømmen som slutbruger. Se derefter på koden, startende med brugergrænsefladekoden - den skal være den nemmeste at genkende - og følg hvert trin på bagsiden helt til databasen.

Når du går videre, skal du tegne et sekvensdiagram for at illustrere, hvad der sker. Hvis du ikke er sikker på, hvad et sekvensdiagram er, eller hvordan man tegner et, skal du tjekke denne gratis vejledning. Hvis du ikke har et godt værktøj til at tegne UML, er her et gratis.

Når du har gennemført dit første sekvensdiagram, skal du ved hjælp af en lokal kopi af kodebasen, som du nemt kan gendanne, begynde at foretage subtile ændringer af nogle af de komponenter, du er stødt på. Se om du kan forudsige virkningerne af dine ændringer på applikationen. Dette er en god måde at teste din forståelse på.

Fortsæt med at gentage denne proces og tilføje til dine diagrammer, indtil du har et komplet billede af hele applikationen (eller i det mindste alle de dele, du er ansvarlig for).

For bonuspoint skal du sørge for at dele dine noter og diagrammer. Sæt dem på et meget synligt sted, hvor den næste udvikler, der kommer sammen, let kan opdage dem. Bare rolig for at gøre dem perfekte eller endda smukke. Bare gør hvad du kan. Hver lille smule hjælper.

Alt i alt er det vigtigste at være tålmodig og undgå at slå dig selv op. Kode er en kompleks ting. Det tager tid at forstå den ældre kode. Forbliv rolig.

Sådan repareres ældre kode

Den største udfordring, du står over for, når du retter gammel kode, er at beslutte, hvor langt du skal gå med din rettelse. Jeg anbefaler dig kraftigt at foretage den mindst mulige rentable ændring først. Dette betyder, at du skal foretage den mindst forstyrrende ændring, der løser problemet fuldstændigt, inden du forsøger at rense og omlægge enhver kode.

Dette giver dig en flugtluge. I værste fald, hvis du bliver trukket væk for at adressere en anden prioritet - eller hvis du har en stram deadline - har du i det mindste trukket sammen en arbejdskode, som du kan falde tilbage på.

Når du har fået din kode til at fungere, kan du begynde at foretage små, trinvise forbedringer, hvis du stadig har tid tilbage.

Martin Fowler har sammensat et katalog over refaktorer, som giver dig en god idé om, hvilke typer ændringer du kan foretage for trinvist at forbedre en kodebase. Tjek det her. Ideen er altid at lade koden være i bedre form, end den var, da du fandt den.

Nogle gange vil du støde på en fejl, der faktisk er resultatet af en strukturel defekt. Disse fejl kan ikke rettes ved en simpel ændring af en eller anden betinget logik. De kræver mere invasive ændringer.

Det er her ting bliver hårde. Du skal være brutalt ærlig over for dig selv om, hvad den mindste levedygtige ændring er. Hver fiber i dit væsen vil ønske at trække koden fra hinanden og omskrive det hele. Gør det ikke!

Hold dig til en hurtig løsning efterfulgt af en trinvis forbedring, der refaktorer den og renser den så meget som tiden tillader. Dit mål er bare at gøre koden lidt bedre hver gang. Jo længere du opretholder codebase, jo bedre bliver det.

For virkelig at få denne tilgang til at fungere, skal du sørge for, at du altid polstrer dine skøn for at give tid til lidt refactoring.

Nogle gange er de strukturelle mangler så dårlige, at en strategi for evigt at lappe bare ikke fungerer. Denne situation er faktisk meget mere sjælden, end du måske tror.

Igen skal du være brutalt ærlig over for dig selv om omkostningerne / fordelen ved en omskrivning eller redesign. Du skal acceptere, at dette i sidste ende vil være en forretningsbeslutning og ikke en teknisk beslutning.

Forbered dig på at sige din sag forretningsmæssigt. Hvad koster det at foretage en større omstrukturering af koden? Hvad er de virkelige forretningsrisici ved ikke at gøre det? Hvis du har en solid sag, vil du til sidst blive hørt. Vær ikke overrasket, hvis det først tager et par flere patches.

Husk: hvis du foretager en større eftersyn, skal du først sørge for, at der er støtte til ændringen og et rimeligt budget til at gå sammen med det. Forsøg ikke at flyve under radaren med dette. Medmindre du selvfølgelig nyder akavede samtaler med ledelsen, når du begynder at bryde ting og mangler deadlines.

Sådan tilføjes nye funktioner til ældre kode

Endelig bliver du til sidst opfordret til at tilføje funktioner til ældre kode. På dette tidspunkt har du en vigtig beslutning at tage. ”Går du med strømmen” af den aktuelle kodebase eller tager du tingene i en ny retning?

Igen råder jeg dig til at være brutalt ærlig i din evaluering. Ville det fortsætte med at følge de mønstre og praksis, der er tydeligt i den eksisterende kodebase, gøre det værre eller bunke på et eksisterende problem?

Det meste af tiden vil du gerne holde tingene stabile. Foretag bare trinvise tilføjelser ved hjælp af de eksisterende mønstre og fremgangsmåder i koden. Genbrug eksisterende elementer. Foretag de mindst forstyrrende ændringer, mens du foretager små, trinvise forbedringer ved rengøring og refactoring.

Hvis du mener, at en ny retning er absolut nødvendig, skal du finde en måde at isolere dine ændringer og parre dem så løst som muligt til den eksisterende kodebase.

Prøv at udskære den nye funktion som et separat projekt. Du kan derefter udsætte en API, der lader den ældre kode tilslutte din nye kode. Dette gør det så, at din nye kode og den gamle ældre kode ikke behøver at vide meget om hinanden.

Dette begynder at blive lidt vanskeligt, når du skal bruge funktionalitet fra den ældre kode for at implementere den nye funktion. Den bedste måde at isolere den gamle kode på fra den nye kode er at bruge adaptermønsteret.

DO Factory har en god forklaring på adaptermønsteret:

“Adaptermønsteret oversætter en grænseflade (et objekts egenskaber og metoder) til en anden. Adaptere tillader programmeringskomponenter at arbejde sammen, som ellers ikke ville være på grund af uoverensstemmende grænseflader. Adaptermønsteret kaldes også Wrapper-mønsteret. Et scenarie, hvor adaptere ofte bruges, er når nye komponenter skal integreres og arbejde sammen med eksisterende komponenter i applikationen. Et andet scenarie er refactoring, hvor dele af programmet omskrives med en forbedret grænseflade, men den gamle kode forventer stadig den oprindelige grænseflade. ”

Her er nogle links til forklaringer og eksempler på forskellige sprog.

  • JavaScript- eksempel på adaptermønsteret
  • C # eksempel på adaptermønsteret
  • Java- eksempel på adaptermønsteret

Vigtigste takeaway

Sammenfattende er her de vigtigste punkter, der hjælper dig med at tackle og i sidste ende erobre enhver kodebase:

  1. Bedøm aldrig ældre kode, eller skift den, før du har taget dig tid til at forstå den fuldt ud.
  2. Sekvensdiagrammer er din ven.
  3. Foretrækker små, inkrementelle forbedringer i forhold til omskrivninger eller ændringer i engros.
  4. Hver ændring skal forsøge at lade koden være lidt bedre stillet, end den var, da du fandt den.
  5. Hvis du har brug for at foretage store ændringer, skal du lave en business case og få godkendelse først.
  6. Når du tilføjer nye funktioner, skal du prøve at "gå med strømmen."
  7. Hvis du har brug for at tage koden i en ny retning, skal du isolere dine ændringer og bruge adaptermønsteret til at integrere.

Forhåbentlig fandt du denne artikel nyttig. Min mission er at hjælpe så mange udviklere, som jeg kan. Venligst ❤ anbefaler ❤ denne historie ved hjælp af det grønne hjerte nedenfor for at hjælpe med at sprede budskabet.

Vil du kode bedre? Deltag i tusinder af udviklere, der modtager værdifulde artikler og information som denne fra mig hver uge gratis . Bare klik her.