Legacies Never Die: Hvordan Håndtere Legacy Code

når begrepet «legacy code» kommer opp, blir det vanligvis sagt eller mottatt med et snev av forakt. En foreløpig Google-søk etter «legacy code memes» bringer opp hundrevis og hundrevis av bilde makroer av folk rive håret ut, ser frazzled, eller enormt skuffet.

Da jeg begynte å jobbe som programvareutvikler 6 måneder siden, hadde jeg ingen anelse om hva arven koden var eller hva som jobbet med det innebar.I løpet av min fjerde måned som junior utvikler ble jeg bedt om å legge til et søkefilter modal til en app bygget av en av mine kolleger for to eller tre år siden. Det virket enkelt nok; jeg hadde brukt mesteparten av de siste fire månedene på å jobbe med en utrolig kompleks app for en annen klient som involverer vår standardstabel: TypeScript/React/Redux / Redux-Saga. Jeg hadde allerede løst mange unike problemer og følte meg trygg på min kodingsevne nok til å lage en enkel modal for å passere søkeparametere til backend.

Som du kanskje har gjettet, var det ikke så enkelt. Men hvorfor?

hva legacy code er og hvorfor det kan være utfordrende å håndtere

Legacy code is code arvet fra en annen utvikler eller team som bruker eldre teknologier som ikke lenger støttes eller har blitt erstattet av en nyere versjon. Mange programmerere sier at «kode blir legacy kode så snart den er skrevet». Den funksjonelle forskjellen mellom» vanlig » kode og eldre kode kan ganske enkelt være at den har forskjellige konvensjoner i forhold til det du er vant til å jobbe med.

i mitt tilfelle, app jeg ble tildelt utnyttet Flow snarere Enn TypeScript, og det var ikke så sterkt skrevet som jeg var vant til. Dette gjorde det litt vanskeligere for meg å forstå strukturen av dataene som ble hentet fra backend. Ingen typer betydde at Jeg kjørte Inn I TypeErrors på runtime mye oftere, noe som kan være vanskelig å feilsøke når du skriver en stor funksjon. På toppen av dette brukte appen en mye eldre versjon Av React som måtte forenes med en kompatibel versjon av komponentbiblioteket jeg ønsket å bruke til å bygge modal.Før jeg kommer inn i det nitty-gritty av hvordan man håndterer legacy code med en følelse av poise og rasjonalitet, vil jeg legge til en ansvarsfraskrivelse at legacy code ikke er så dårlig, og å jobbe med et legacy project trenger ikke å være forferdelig. Tvert imot lærte arbeidet med legacy code meg å være fleksibel, tålmodig og fremfor alt, opplevelsen tillot meg sjansen til å løse problemer med et nytt perspektiv i en ny sammenheng.faktisk gjorde det meg til en bedre utvikler enn jeg var før jeg begynte å jobbe gjennom den nevnte kodebasen, og forhåpentligvis kan ditt eldre prosjekt også lære deg noe.

hvordan håndtere legacy kode på et teknisk nivå

Foto Av Jeff Sheldon på Unsplash

Les dokumentasjon og kode kommentarer når det er mulig

i en perfekt verden, har hver kodebase en robust README som inneholder konsise forklaringer på hvordan prosjektet fungerer, kode kommentarer som forklarer den eksakte logikken i den opprinnelige forfatteren, og hele programmet gir mening. Dette er imidlertid sjelden tilfelle. Mange READMEs blir ikke oppdatert etter hvert som prosjekter utvikler seg, folk glemmer å skrive kommentarer, antar at deres logikk er åpenbar for en ny utvikler, eller de går rett og slett tom for tid til å ta vare på disse tingene.

Se på kodebasen som helhet

hvis du er tapt og ikke vet hvor du skal begynne, spør deg selv disse spørsmålene:

• hva er appens formål?
• hvordan flyter data gjennom appen?
• Hvordan din funksjon passer inn i app?

når du kan få en følelse av det store bildet, er det lettere å finne ut hvordan du best kan takle problemet. Kanskje du må opprette en ny fil og opprette en ny komponent. Kanskje du må skrive en verktøyfunksjon og teste den. Uansett hva som er tilfelle, er det å forstå den bredere konteksten til problemet ditt et godt første skritt for å skape en løsning.

Test appen manuelt og med enhetstester når det er mulig

Å Bryte en app midlertidig mens du legger til en ny funksjon, er en uunngåelighet, uansett hvilket nivå av utvikler du er. Dette er normalt og forventet, spesielt hvis du er ny på jobben, jobber i en eldre kodebase med en ukjent stabel, eller en kombinasjon av de to.Den beste måten å forhindre at disse bruddene blir langsiktige problemer, er å teste appen grundig med både enhetstester og manuelle tester. Å ha disse testene på plass og vite nøyaktig hva slags dekning du får ut av dem, vil spare deg og fremtidige utviklere mye tid. I tillegg strenge tester gjøre app mer skalerbar og også gi deg en litte dopamin rush hver gang testene kjøre ren.

for enhetstesting kan du bruke testrammer som Jest eller Jasmine.

for manuelle tester vil du utvikle en testmatrise og sørge for at dokumentet er tilgjengelig for fremtidige utviklere. For matrisen vil du definere et sett med handlinger, forventet oppførsel, den faktiske oppførselen når du tester den, og andre detaljer som er viktige, slik som:

jeg skal dekke hvordan du implementerer begge typer testing effektivt i arbeidsflyten din i et fremtidig blogginnlegg.

Be om hjelp

Forutsatt at prosjektet ditt ble skrevet av en nåværende eller tidligere ansatt på arbeidsplassen din, vet noen andre sikkert hva som skjer i appen, eller vet i det minste nok til å få deg unstuck. Å lære å svelge din stolthet og spørre noen andre er et ubehagelig skritt for noen, men en nødvendig for å vokse som utvikler, og kanskje din kollega kan lære deg noen nye triks.En god måte å gjøre effektiv bruk av din tid (og deres) er å formulere informerte spørsmål. Prøv å gå tilbake til å se på kodebasen som helhet og finne ut hullene i forståelsen din. Ikke bare vil det hjelpe dem å få en bedre følelse av hva problemet er, men det viser at du tok initiativ til å prøve å løse problemet på egen hånd først.

Vet når du skal kutte tapene dine

hvis du bruker for mye tid på å prøve å få foten i døren og ikke har gjort noen alvorlige skritt mot å implementere funksjonen etter å ha prøvd trinnene ovenfor, kan det være verdt å refactoring koden rundt funksjonen din. Ikke gi opp for lett, men også huske på hva tidsfrister er og hva prosjektlederen forventer av deg.

Når det er sagt, er det ulemper å gå om det på den måten:

• Omskrivningskode kan introdusere feil, selv om dette kan bli noe omgått med god enhetstesting.Omskrivningskode kan fjerne skjult funksjonalitet, men dette kan også omgå med gode enhetstester.
• hvis du er presset for tid, skrive kode utenfor funksjonen i tillegg til funksjonen kan faktisk være mer tidkrevende enn bare å bygge rundt det.

alt i alt, bruk din beste dømmekraft. Det er fordeler og ulemper for begge valg, og det er alt avhengig av dine individuelle forhold og prosjektbudsjett.

hvordan håndtere eldre kode på et psykologisk nivå

Foto Av Simon Migaj På Unsplash

Nå som vi har dekket de tekniske aspektene ved å håndtere eldre kode, la oss snakke om hvordan vi skal håndtere det ved hjelp av våre myke ferdigheter. Tross alt er utviklere mennesker, ikke bare kodende roboter, og å håndtere utfordrende problemer på prosjekter som krever kreativitet og forfatterskap, kan være følelsesmessig beskattende, ikke bare for deg, men også for dine kolleger.

Vær ydmyk og snill

Dette er noe jeg vil sheepishly innrømme at jeg trenger å øve mer. Da jeg først ble tildelt filter modal project, var jeg ganske vokal om hvordan janky og unappealing koden skulle håndtere mens den opprinnelige forfatteren av koden satt 15 meter unna meg. Jeg hadde tenkt at mine kommentarer skulle være en vits, men i ettertid innser jeg at jeg var arrogant og sårende, og at jeg burde vært mer empatisk.

Det er mange faktorer som kan føre til at arvskoden ser «av» som du bør ta hensyn til før du begynner å kritisere forfatteren eller anta det verste om dem (dette er løst knyttet til den grunnleggende attribusjonsfeilen!).

den opprinnelige forfatteren kan ha hatt sine grunner til å skrive kode slik de gjorde.

tidsbegrensninger og teknologibegrensninger kan føre til at en person skriver kode som fungerer, men ikke nødvendigvis har den beste konvensjonen. Hvis du ser deg selv i en situasjon med ikke nok tid, utdaterte verktøy og en todo-liste en kilometer lang, vil du sannsynligvis ikke skrive den beste koden heller!

Konvensjoner endres.

i eldre Olio Apps-prosjekter bruker konvensjonen for kode enkelt anførselstegn for å erklære strenger, og to mellomrom var lik en fane. Vi hadde flere små React-komponenter nestet inne i en enkelt fil. I vår nåværende konvensjon bruker vi doble anførselstegn og fire mellomrom, og Hver React-komponent, uansett hvor liten, lever i sin egen.tsx – fil icomponent – katalogen. Om noen år er jeg sikker på at det også vil endre seg.

all kode blir til slutt legacy

dette knytter seg tilbake til forrige punkt: koden din vil til slutt være legacy. Når du beveger deg opp stigen av anciennitet, vil nye utviklere bli ansatt på og må opprettholde din gamle kode. Du kan skrive ren, feilfri, TØRR kode, men når konvensjoner endres eller trender endres, kan de nye utviklerne se koden din på samme måte som du ser den eldre koden til andre.

Ta stolthet i de små suksessene

Det er ikke lett å jobbe utenfor dine vanlige konvensjoner; det er en grunn til den store troven av memes og vitser om å håndtere eldre kode. Hvis du noen gang har lært et språk utenfor morsmålet ditt, vet du hvordan det føles å glemme et ord eller uttrykk på ditt andre språk, men husk det på morsmålet ditt og ikke kunne oversette over gapet. Det samme gjelder for endring mellom moderne og eldre konvensjoner. Noen ganger tar det bare et minutt å gjenvinne lagrene dine.For å kunne navigere i eldre kode, viser du din evne til å være tilpasningsdyktig, noe som er en viktig ferdighet som fordeler deg på din nåværende jobb og alle dine fremtidige jobber, enten disse jobbene er i teknologifeltet eller ikke. Legacy code er den perfekte lekeplassen for å øve denne ferdigheten.

Som konklusjon:

Bruk denne gangen til å styrke din egen kodeskriving

Nå som du har hatt erfaring med å jobbe i en eldre kodebase, bør du komme vekk fra det med en bedre følelse av hva du liker og ikke liker når det gjelder verktøy og konvensjoner. Dette er ting du kan fortsette med i fremtidige prosjekter, og gjøre deg bedre til å gjennomgå andres kode, tilby konstruktiv kritikk og gi mentorskap.

Utvikle apper for brukeren og den fremtidige utvikleren

Enten du har hatt erfaring med god dokumentasjon og kodekommentarer eller ingen dokumentasjon eller kodekommentarer, kan du se hvordan både dokumentasjon og kommentarer er kraftige verktøy for å hjelpe fremtidige utviklere å navigere i prosjektet. Du deler et felles mål om å ha en jevn, funksjonell og TØRR app; opprettholde dokumentasjonen og etterlate informative kodekommentarer er en god måte å bygge bro over dette gapet.

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

jeg har nevnt dette et par ganger allerede, men det er viktig å gjenta at koden din vil være arv også, uansett HVOR TØRR og uberørt koden din og logikken er.

den viktigste takeaway er å være fleksibel, ydmyk, og at du definitivt kan lære nye triks fra gammel kode.