Legacies Never Die: Sådan håndteres Legacy Code

Når udtrykket “legacy code” kommer op, bliver det normalt sagt eller modtaget med en smule foragt. En foreløbig Google-søgning efter” legacy code memes ” bringer hundreder og hundreder af billedmakroer af mennesker, der river deres hår ud, ser forvirret ud, eller enormt skuffet.

da jeg begyndte at arbejde som programudvikler for 6 måneder siden, anede jeg ikke, hvilken arvskode der var, eller hvad arbejdet med det medførte.

i løbet af min fjerde måned som juniorudvikler blev jeg bedt om at tilføje et søgefiltermodal til en app bygget af en af mine kolleger for to eller tre år siden. Det virkede let nok; jeg havde brugt størstedelen af de sidste fire måneder på at arbejde på en utrolig kompleks app til en anden klient, der involverede vores standard stack: TypeScript/React/reduce/reduce-Saga. Jeg havde allerede løst mange unikke problemer og følte mig sikker på min kodningsevne nok til at lave en simpel modal til at videregive forespørgselsparametre til backend.

som du måske har gættet, var det næsten ikke så simpelt. Men hvorfor?

hvad legacy code er, og hvorfor det kan være udfordrende at håndtere

Legacy code er kode arvet fra en anden udvikler eller et team, der bruger ældre teknologier, der ikke længere understøttes eller er blevet erstattet af en nyere version. Mange programmører siger ,at”kode bliver arvskode, så snart den er skrevet”. Den funktionelle forskel mellem” almindelig ” kode og ældre kode kan simpelthen være, at den har forskellige konventioner sammenlignet med det, du er vant til at arbejde med.

i mit tilfælde blev appen jeg tildelt brugt strøm snarere end TypeScript, og det var ikke så stærkt skrevet som jeg var vant til. Dette gjorde det lidt sværere for mig at forstå strukturen af de data, der blev hentet fra backend. Ingen typer betød, at jeg løb ind i TypeErrors på runtime meget oftere, hvilket kan være svært at debugge, når du skriver en stor funktion. Oven i købet, appen brugte en meget ældre version af React, som skulle forenes med en kompatibel version af komponentbiblioteket, jeg ville bruge til at opbygge Modalen.

før jeg kommer ind i det nitty-gritty af, hvordan man håndterer legacy code med en følelse af poise og rationalitet, vil jeg tilføje en ansvarsfraskrivelse om, at legacy code ikke er alt dårligt, og at arbejde på et legacy project behøver ikke at være forfærdeligt. Tværtimod, at arbejde med legacy code lærte mig at være fleksibel, tålmodig, og frem for alt andet, oplevelsen tillod mig chancen for at løse problemer med et nyt perspektiv i en ny sammenhæng.

faktisk gjorde det mig til en bedre Udvikler end jeg var, før jeg begyndte at arbejde gennem den førnævnte kodebase, og forhåbentlig kan dit arvsprojekt også lære dig noget.

Sådan håndteres med arvskode på teknisk niveau

foto af Jeff Sheldon på Unsplash

Læs dokumentation og kodekommentarer, når det er muligt

i en perfekt verden har hver kodebase en robust README, der indeholder kortfattede forklaringer på, hvordan projektet fungerer, kodekommentarer, der forklarer den nøjagtige logik for den oprindelige forfatter, og hele applikationen giver perfekt mening. Dette er dog sjældent tilfældet. Mange READMEs bliver ikke opdateret, når projekter udvikler sig, folk glemmer at skrive kommentarer, antager, at deres logik er indlysende for en ny udvikler, eller de løber simpelthen tør for tid til at tage sig af disse ting.

se på kodebasen som helhed

Hvis du er tabt og ikke ved, hvor du skal starte, skal du stille dig selv disse spørgsmål:

• hvad er appens formål?
• hvordan strømmer data gennem appen?
• hvordan passer din funktion ind i appen?

når du kan få en fornemmelse af det store billede, er det lettere at finde ud af, hvordan du bedst kan løse problemet. Måske skal du oprette en ny fil og oprette en ny komponent. Måske skal du skrive en hjælpefunktion og teste den. Uanset hvad der er tilfældet, er forståelse af den bredere kontekst af dit problem et godt første skridt til at skabe en løsning.

Test appen manuelt og med enhedstest, når det er muligt

det er en uundgåelighed at bryde en app midlertidigt, mens du tilføjer en ny funktion, uanset hvilket niveau af Udvikler du er. Dette er normalt og forventet, især hvis du er ny på jobbet, arbejder i en ældre kodebase med en ukendt stak eller en kombination af de to.

den bedste måde at forhindre, at disse brud bliver langsigtede problemer, er at teste din app grundigt med både enhedstest og manuelle test. At have disse tests på plads og vide præcis, hvilken slags dækning du får ud af dem, sparer dig og fremtidige udviklere meget tid. Derudover gør strenge tests appen mere skalerbar og giver dig også en lille dopaminhastighed, hver gang dine test kører rent.

til enhedstest kan du bruge testrammer som Jest eller Jasmine.

for manuelle tests skal du udvikle en testmatrice og sørge for, at dokumentet er tilgængeligt for fremtidige udviklere. For matricen vil du definere et sæt handlinger, den forventede adfærd, den faktiske adfærd, når du tester den, og andre detaljer, der er vigtige, som sådan:

Jeg vil dække, hvordan du implementerer begge typer test effektivt i din arbejdsgang i et fremtidigt blogindlæg.

Bed om hjælp

Hvis du antager, at dit projekt er skrevet af en nuværende eller tidligere medarbejder på din arbejdsplads, ved en anden sandsynligvis, hvad der foregår i appen, eller i det mindste ved nok til at få dig til at løsne. At lære at sluge din stolthed og spørge en anden er et ubehageligt skridt for nogle, men et nødvendigt skridt til at vokse som udvikler, og måske kan din kollega lære dig et par nye tricks.

en god måde at gøre effektiv brug af din tid (og deres) er at formulere informerede spørgsmål. Prøv at gå tilbage til at se på kodebasen som helhed og finde ud af hullerne i din forståelse. Ikke alene vil det hjælpe dem til at få en bedre fornemmelse af, hvad dit problem er, men det viser, at du tog initiativ til at forsøge at løse problemet på egen hånd først.

ved, hvornår du skal reducere dine tab

Hvis du bruger for meget tid på at få din fod i døren og ikke har gjort noget seriøst skridt mod at implementere funktionen efter at have prøvet ovenstående trin, kan det være værd at refactoring koden omkring din funktion. Giv ikke op for let, men husk også, hvad dine deadlines er, og hvad din projektleder forventer af dig.

når det er sagt, er der ulemper ved at gå på den måde:

• Omskrivningskode kan introducere fejl, selvom dette kan omgås noget med god enhedstest.
• omskrivning af kode kan fjerne skjult funktionalitet, selvom dette også kan omgås med gode enhedstest.
• hvis du er presset til tiden, kan det faktisk være mere tidskrævende at skrive kode uden for din funktion ud over din funktion end bare at bygge omkring den.

alt i alt skal du bruge din bedste vurdering. Der er fordele og ulemper ved begge valg, og det hele afhænger af dine individuelle forhold og projektbudget.

Sådan håndteres legacy code på et psykologisk niveau

foto af Simon Migaj på Unsplash

nu hvor vi har dækket de tekniske aspekter ved håndtering af legacy code, lad os tale om, hvordan vi skal håndtere det ved hjælp af vores bløde færdigheder. Når alt kommer til alt er udviklere mennesker, ikke kun kodende robotter, og at håndtere udfordrende problemer på projekter, der kræver kreativitet og forfatterskab, kan være følelsesmæssigt beskattende, ikke kun for dig, men også for dine kolleger.

Vær ydmyg og venlig

dette er noget, som jeg fårigt indrømmer, at jeg har brug for at øve mere. Da jeg først blev tildelt filtermodal-projektet, Jeg var ret højlydt om, hvor janky og ikke tiltalende koden skulle håndtere, mens den oprindelige forfatter af koden sad 15 fødder væk fra mig. Jeg havde til hensigt, at mine kommentarer skulle være en vittighed, men efterhånden erkender jeg, at jeg var arrogant og sårende, og at jeg burde have været mere empatisk.

der er en masse faktorer, der kan føre til arv kode ser “off”, som du bør tage hensyn til, før du begynder at kritisere forfatteren eller antage det værste om dem (Dette er løst bundet til den grundlæggende tilskrivning fejl!).

den oprindelige forfatter kan have haft deres grunde til at skrive kode som de gjorde.

tidsbegrænsninger og teknologibegrænsninger kan få en person til at skrive kode, der fungerer, men ikke nødvendigvis har den bedste konvention. Hvis du forestiller dig selv i en situation med ikke nok tid, forældede værktøjer og en todo-liste en kilometer lang, ville du sandsynligvis heller ikke skrive den bedste kode!

konventioner ændres.

i ældre Olio Apps-projekter bruger konventionen for kode enkelte citater til at erklære strenge, og to mellemrum var lig med en fane. Vi havde flere små React-komponenter indlejret inde i en enkelt fil. I vores nuværende konvention bruger vi dobbelt citater og fire mellemrum, og hver React-komponent, uanset hvor lille, lever i sin egen .tsx fil i component mappe. Og om flere år er jeg sikker på, at det også vil ændre sig.

al kode bliver til sidst legacy

dette binder tilbage til det foregående punkt: din kode vil til sidst være legacy. Når du bevæger dig op ad stigen af anciennitet, nye udviklere vil blive ansat på og bliver nødt til at vedligeholde din gamle kode. Du kan skrive ren, fejlfri, tør kode, men når konventioner ændres eller tendenser ændres, kan de nye udviklere muligvis se din kode på samme måde som du ser andres ældre kode.

vær stolt af de små succeser

det er ikke let at arbejde uden for dine sædvanlige konventioner; der er en grund til den enorme trove af memes og vittigheder om at håndtere arvskode. Hvis du nogensinde har lært et sprog uden for dit modersmål, ved du, hvordan det føles at glemme et ord eller udtryk på dit andet sprog, men husk det på dit modersmål og ikke være i stand til at oversætte over kløften. Det samme gælder for at skifte mellem moderne og ældre konventioner. Nogle gange tager det bare et minut at genvinde dine lejer.

når du er i stand til at navigere i ældre kode, viser du din evne til at være tilpasningsdygtig, hvilket er en vigtig færdighed, der gavner dig på dit nuværende job og alle dine fremtidige job, uanset om disse job er inden for teknologiområdet eller ej. Legacy code er den perfekte legeplads til at øve denne færdighed.

afslutningsvis:

brug denne tid til at styrke din egen kodeskrivning

nu hvor du har haft oplevelsen af at arbejde i en ældre kodebase, skal du komme væk fra den med en bedre fornemmelse af, hvad du kan lide og ikke kan lide med hensyn til værktøjer og konventioner. Dette er ting, du kan fortsætte med i fremtidige projekter, og gøre dig bedre til at gennemgå andres kode, tilbyde konstruktiv kritik, og give mentorskab.

Udvikl apps til brugeren og den fremtidige Udvikler

uanset om du har haft oplevelsen af god dokumentation og kodekommentarer eller ingen dokumentation eller kodekommentarer, kan du se, hvordan både dokumentation og kommentarer er effektive værktøjer til at hjælpe fremtidige udviklere med at navigere i projektet. Du deler et fælles mål om at ønske en glat, funktionel og tør app; vedligeholdelse af dokumentationen og efterlader informative kodekommentarer er en god måde at bygge bro over dette hul.

Husk, at din kode også vil være arv en dag

jeg har allerede nævnt dette et par gange, men det er vigtigt at gentage, at din kode også vil være arv, uanset hvor tør og uberørt din kode og logik er.

den vigtigste afhentning er at være fleksibel, ydmyg, og at du helt sikkert kan lære nye tricks fra gammel kode.