Legacies Never Die: hur man hanterar äldre kod

När termen” äldre kod ” kommer upp, är det vanligtvis sagt eller mottaget med en aning av förakt. En preliminär Google-sökning efter” legacy code memes ” tar upp hundratals och hundratals bildmakron av människor som sliter ut håret, ser frazzled eller enormt besviken.

När jag började arbeta som mjukvaruutvecklare 6 månader sedan, jag hade ingen aning om vad äldre kod var eller vad som arbetar med det innebar.

under min fjärde månad som juniorutvecklare blev jag ombedd att lägga till ett sökfiltermodal till en app byggd av en av mina medarbetare för två eller tre år sedan. Det verkade lätt nog; jag hade spenderat majoriteten av de senaste fyra månaderna på en otroligt komplex app för en annan klient som involverade vår standardstack: TypeScript/React/Redux/Redux-Saga. Jag hade redan löst många unika problem och kände mig säker på min kodningsförmåga nog att göra en enkel modal för att skicka frågeparametrar till backend.

som du kanske har gissat var det inte så enkelt. Men varför?

vad äldre kod är och varför det kan vara utmanande att hantera

äldre kod är kod som ärvs från en annan utvecklare eller ett team som använder äldre tekniker som inte längre stöds eller har ersatts av en nyare version. Många programmerare säger att”kod blir äldre kod så snart den är skriven”. Den funktionella skillnaden mellan” vanlig ” kod och äldre kod kan helt enkelt vara att den har olika konventioner jämfört med vad du är van vid att arbeta med.

i mitt fall var appen som jag tilldelades utnyttjat flöde snarare än TypeScript, och det var inte så starkt skrivet som jag var van vid. Detta gjorde det lite svårare för mig att förstå strukturen på de data som hämtades från backend. Inga typer innebar att jag körde in i TypeErrors på runtime mycket oftare, vilket kan vara svårt att felsöka när du skriver en stor funktion. Utöver detta använde appen en mycket äldre version av React som behövde förenas med en kompatibel version av komponentbiblioteket som jag ville använda för att bygga Modalen.

innan jag kommer in i nitty-gritty om hur man hanterar äldre kod med en känsla av poise och rationalitet, vill jag lägga till en ansvarsfriskrivning att äldre kod inte är allt dåligt och att arbeta med ett äldre projekt behöver inte vara hemskt. Tvärtom, att arbeta med äldre kod lärde mig att vara flexibel, tålmodig och framför allt gav erfarenheten mig chansen att lösa problem med ett nytt perspektiv i ett nytt sammanhang.

faktum är att det gjorde mig till en bättre utvecklare än jag var innan jag började arbeta genom ovannämnda kodbas, och förhoppningsvis kan ditt äldre projekt lära dig något också.

hur man hanterar med äldre kod på teknisk nivå

foto av Jeff Sheldon på Unsplash

Läs dokumentation och kodkommentarer när det är möjligt

i en perfekt värld har varje kodbas en robust README som innehåller kortfattade förklaringar av hur projektet fungerar, kodkommentarer som förklarar den ursprungliga författarens exakta logik och hela applikationen är perfekt. Detta är dock sällan fallet. Många READMEs blir inte uppdaterade när projekt utvecklas, folk glömmer att skriva kommentarer, antar att deras logik är uppenbar för en ny utvecklare, eller de tar helt enkelt slut på tid att ta hand om dessa saker.

titta på kodbasen som helhet

om du är vilse och inte vet var du ska börja, fråga dig själv dessa frågor:

• Vad är appens syfte?
• hur flyter data genom appen?
• hur passar din Funktion in i appen?

När du kan få en känsla av den stora bilden är det lättare att ta reda på hur man bäst kan hantera problemet. Kanske måste du skapa en ny fil och skapa en ny komponent. Kanske måste du skriva en verktygsfunktion och testa den. Hur som helst, att förstå det bredare sammanhanget med ditt problem är ett bra första steg för att skapa en lösning.

testa appen manuellt och med enhetstester när det är möjligt

att bryta en app tillfälligt medan du lägger till en ny funktion är en oundviklighet, oavsett vilken nivå av utvecklare du är. Detta är normalt och förväntat, särskilt om du är ny på jobbet, arbetar i en äldre kodbas med en okänd stack eller någon kombination av de två.

det bästa sättet att förhindra att dessa brott blir långsiktiga problem är att testa din app noggrant med både enhetstester och manuella tester. Att ha dessa tester på plats och veta exakt vilken typ av täckning du får ut av dem kommer att spara dig och framtida utvecklare mycket tid. Dessutom gör rigorösa tester appen mer skalbar och ger dig också en liten dopaminhopp varje gång dina tester går rena.

för enhetstestning kan du använda testramar som Jest eller Jasmine.

för manuella tester vill du utveckla en testmatris och se till att dokumentet är tillgängligt för framtida utvecklare. För matrisen vill du definiera en uppsättning åtgärder, det förväntade beteendet, det faktiska beteendet när du testar det och andra detaljer som är viktiga, så här:

Jag kommer att täcka hur man implementerar båda typerna av testning effektivt i ditt arbetsflöde i ett framtida blogginlägg.

be om hjälp

förutsatt att ditt projekt skrevs av en nuvarande eller tidigare anställd på din arbetsplats, vet någon annan förmodligen vad som händer i appen, eller åtminstone vet tillräckligt för att få dig att ta bort. Att lära sig att svälja din stolthet och fråga någon annan är ett obehagligt steg för vissa, men ett nödvändigt steg för att växa som utvecklare, och kanske kan din kollega lära dig några nya knep.

ett bra sätt att effektivt använda din tid (och deras) är att formulera informerade frågor. Försök att gå tillbaka till att titta på kodbasen som helhet och ta reda på luckorna i din förståelse. Inte bara kommer det att hjälpa dem att få en bättre känsla för vad ditt problem är, men det visar att du tog initiativ till att försöka lösa problemet på egen hand först.

vet när du ska minska dina förluster

Om du spenderar för mycket tid på att försöka få din fot i dörren och inte har gjort några allvarliga steg mot att implementera funktionen efter att ha försökt stegen ovan kan det vara värt att refactoring koden runt din funktion. Ge inte upp för lätt, men kom också ihåg vad dina tidsfrister är och vad din projektledare förväntar sig av dig.

som sagt, det finns nackdelar med att gå om det på det sättet:

• Omskrivningskod kan introducera buggar, även om detta kan kringgås något med bra enhetstestning.
• Omskrivningskod kan ta bort dold funktionalitet, även om detta också kan kringgås med bra enhetstester.
• Om du har ont om tid kan det faktiskt vara mer tidskrävande att skriva kod utanför din funktion utöver din funktion än att bara bygga runt den.

allt som allt, Använd ditt bästa omdöme. Det finns för-och nackdelar för båda valen, och det är allt beroende av dina individuella omständigheter och projektbudget.

hur man hanterar äldre kod på psykologisk nivå

foto av Simon Migaj på Unsplash

Nu när vi har täckt de tekniska aspekterna av att hantera äldre kod, låt oss prata om hur man hanterar det med våra mjuka färdigheter. När allt kommer omkring är utvecklare människor, inte bara kodande robotar, och att hantera utmanande problem på projekt som kräver kreativitet och författarskap kan vara känslomässigt beskattande, inte bara för dig utan också för dina medarbetare.

var ödmjuk och snäll

detta är något som jag får erkänna att jag behöver träna mer. När jag först tilldelades filtermodalprojektet var jag ganska vokal om hur janky och otrevlig koden var att hantera medan den ursprungliga författaren av koden satt 15 meter från mig. Jag tänkte att mina kommentarer skulle vara ett skämt, men i efterhand inser jag att jag var arrogant och skadlig och att jag borde ha varit mer empatisk.

det finns många faktorer som kan leda till att äldre kod ser ”av” som du bör ta hänsyn till innan du börjar kritisera författaren eller antar det värsta om dem (Detta är löst knutet till det grundläggande attributionsfelet!).

den ursprungliga författaren kan ha haft sina skäl för att skriva kod som de gjorde.

tidsbegränsningar och teknikbegränsningar kan få en person att skriva kod som fungerar men inte nödvändigtvis har den bästa konventionen. Om du föreställer dig själv i en situation med inte tillräckligt med tid, föråldrade verktyg och en todo-lista en mil lång, skulle du förmodligen inte skriva den bästa koden heller!

konventioner ändras.

i äldre Olio Apps-projekt använder konventionen för kod enkla citat för att deklarera strängar, och två mellanslag var lika med en flik. Vi hade flera små React-komponenter kapslade inuti en enda fil. I vår nuvarande konvention använder vi dubbla citat och fyra mellanslag, och varje React-komponent, oavsett hur liten, lever i sin egen .tsx fil i component katalog. Och om flera år är jag säker på att det kommer att förändras också.

all kod blir så småningom arv

detta knyter tillbaka till föregående punkt: din kod kommer så småningom att vara arv. När du flyttar uppför senioritetsstegen kommer nya utvecklare att hyras på och måste behålla din gamla kod. Du kan skriva ren, felfri, torr kod, men när konventioner ändras eller trender ändras kan de nya utvecklarna se din kod på samma sätt som du ser andras äldre kod.

stolta över de små framgångarna

det är inte lätt att arbeta utanför dina vanliga konventioner; det finns en anledning till den enorma troven av memes och skämt om att hantera äldre kod. Om du någonsin har lärt dig ett språk utanför ditt modersmål vet du hur det känns att glömma ett ord eller en term på ditt andra språk, men kom ihåg det på ditt modersmål och inte kunna översätta över klyftan. Detsamma gäller för förändring mellan moderna och äldre konventioner. Ibland tar det bara en minut att återfå dina lager.

För att lyckas navigera i äldre kod visar du din förmåga att vara anpassningsbar, vilket är en viktig färdighet som gynnar dig vid ditt nuvarande jobb och alla dina framtida jobb, oavsett om dessa jobb är inom teknikområdet eller inte. Legacy code är den perfekta lekplatsen för att öva denna färdighet.

Sammanfattningsvis:

använd den här tiden för att stärka din egen kodskrivning

Nu när du har haft erfarenhet av att arbeta i en äldre kodbas, bör du komma ifrån det med en bättre känsla av vad du gillar och inte gillar när det gäller verktyg och konventioner. Det här är saker du kan fortsätta med i framtida projekt och göra dig bättre på att granska andras kod, erbjuda konstruktiv kritik och ge mentorskap.

utveckla appar för användaren och den framtida utvecklaren

oavsett om du har haft erfarenhet av bra dokumentation och kodkommentarer eller ingen dokumentation eller kodkommentarer kan du se hur både dokumentation och kommentarer är kraftfulla verktyg för att hjälpa framtida utvecklare att navigera i projektet. Du delar ett gemensamt mål att vilja ha en smidig, funktionell och torr app; att upprätthålla dokumentationen och lämna informativa kodkommentarer är ett bra sätt att överbrygga det gapet.

kom ihåg att din kod kommer att vara arv En dag också

Jag har nämnt detta några gånger redan, men det är viktigt att upprepa att din kod kommer att vara arv också, oavsett hur torr och orörd din kod och logik är.

den viktigaste takeaway är att vara flexibel, ödmjuk och att du definitivt kan lära dig nya knep från gammal kod.