Legacy Never Die: How To Handle Legacy Code

wanneer de term “legacy code” opduikt, wordt het meestal gezegd of ontvangen met een vleugje minachting. Een voorlopige Google-zoekopdracht voor “legacy code memes” brengt honderden en honderden beeld macro ‘ s van mensen scheuren hun haar uit, op zoek frazzled, of enorm teleurgesteld.

toen ik begon te werken als software ontwikkelaar 6 maanden geleden, had ik geen idee wat legacy code was of wat het werken met het inhield.

tijdens mijn vierde maand als junior Ontwikkelaar, werd ik gevraagd om een zoekfilter modal toe te voegen aan een app die twee of drie jaar geleden door een van mijn collega ‘ s is gebouwd. Het leek gemakkelijk genoeg; ik had het grootste deel van de laatste vier maanden gewerkt aan een ongelooflijk complexe app voor een andere client met onze standaard stack: TypeScript/React/Redux/Redux-Saga. Ik had al veel unieke problemen opgelost en voelde vertrouwen in mijn codering vermogen genoeg om een eenvoudige modal te geven query parameters aan de backend te maken.

zoals je misschien al geraden hebt, was het lang niet zo eenvoudig. Maar waarom?

wat legacy code is en waarom het een uitdaging kan zijn om met

om te gaan Legacy code is code die is overgenomen van een andere ontwikkelaar of team die gebruik maakt van oudere technologieën die niet langer worden ondersteund of zijn vervangen door een nieuwere versie. Veel programmeurs zeggen dat “code legacy code wordt zodra het geschreven is”. Het functionele verschil tussen” gewone ” code en legacy code kan gewoon zijn dat het verschillende conventies heeft in vergelijking met wat je gewend bent om mee te werken.

in mijn geval gebruikte de app die ik toegewezen kreeg Flow in plaats van TypeScript, en het was niet zo sterk getypt als ik gewend was. Dit maakte het een beetje moeilijker voor mij om de structuur van de gegevens die werd opgehaald van de backend te begrijpen. Geen typen betekende dat ik veel vaker typefouten op runtime tegenkwam, wat moeilijk te debuggen kan zijn wanneer je een grote functie schrijft. Op de top van deze, de app gebruikt een veel oudere versie van React die moest worden verzoend met een compatibele versie van de component bibliotheek die ik wilde gebruiken om de modal te bouwen.

voordat ik in de nitty-gritty van hoe om te gaan met legacy code met een gevoel van evenwicht en rationaliteit, wil ik een disclaimer toe te voegen dat legacy code is niet allemaal slecht en werken aan een legacy project hoeft niet verschrikkelijk te zijn. Integendeel, werken aan legacy code leerde me om flexibel, geduldig te zijn, en bovenal, de ervaring gaf me de kans om problemen op te lossen met een nieuw perspectief in een nieuwe context.

in feite maakte het me een betere ontwikkelaar dan ik was voordat ik begon te werken door de bovengenoemde codebase, en hopelijk kan je legacy project je ook iets leren.

hoe om te gaan met legacy code op technisch niveau

foto door Jeff Sheldon op Unsplash

lees documentatie en codecommentaren indien mogelijk

In een perfecte wereld heeft elke codebase een robuuste README die beknopte uitleg bevat over hoe het project werkt, codecommentaren die de exacte logica van de oorspronkelijke auteur uitleggen, en de hele toepassing is volkomen logisch. Dit is echter zelden het geval. Veel READMEs worden niet bijgewerkt als projecten zich ontwikkelen, mensen vergeten commentaar te schrijven, gaan ervan uit dat hun logica duidelijk is voor een nieuwe ontwikkelaar, of ze hebben gewoon geen tijd meer om voor die dingen te zorgen.

Kijk naar de codebase als geheel

Als u verdwaald bent en niet weet waar u moet beginnen, stel uzelf de volgende vragen:

• Wat is het doel van de app?
• Hoe stromen gegevens door de app?
• Hoe past uw functie in de app?

wanneer je een idee krijgt van het grote plaatje, is het makkelijker om uit te zoeken hoe je het probleem het beste kunt aanpakken. Misschien moet je een nieuw bestand aanmaken en een nieuw component aanmaken. Misschien moet je een utility functie schrijven en testen. Wat ook het geval is, het begrijpen van de bredere context van uw probleem is een goede eerste stap naar het creëren van een oplossing.

Test de app handmatig en met unit tests waar mogelijk

een app Tijdelijk breken terwijl het toevoegen van een nieuwe functie is een onvermijdelijkheid, ongeacht welk niveau van ontwikkelaar je bent. Dit is normaal en verwacht, vooral als je nieuw bent in de taak, werken in een legacy codebase met een onbekende stack, of een combinatie van de twee.

de beste manier om te voorkomen dat deze breuken problemen op lange termijn worden is om uw app grondig te testen met zowel unit tests als handmatige tests. Het hebben van deze tests op zijn plaats en precies te weten wat voor soort dekking je krijgt uit hen bespaart u en toekomstige ontwikkelaars een hoop tijd. Bovendien, rigoureuze tests maken de app schaalbaarder en ook geven u een beetje dopamine rush elke keer dat uw tests schoon lopen.

voor unit testing kunt u test frameworks zoals Jest of Jasmine gebruiken.

voor handmatige tests wilt u een testmatrix ontwikkelen en ervoor zorgen dat het document toegankelijk is voor toekomstige ontwikkelaars. Voor de matrix wilt u een set acties definiëren, het verwachte gedrag, het werkelijke gedrag wanneer u het test, en alle andere details die belangrijk zijn, zoals:

in een toekomstige blogpost zal ik u vertellen hoe u beide soorten testen efficiënt kunt implementeren in uw workflow.

vraag om hulp

aangenomen dat uw project is geschreven door een huidige of voormalige werknemer op uw werkplek, weet iemand anders waarschijnlijk wat er gaande is in de app, of weet tenminste genoeg om u los te maken. Leren om je trots in te slikken en iemand anders te vragen is voor sommigen een ongemakkelijke stap, maar een noodzakelijke voor het groeien als ontwikkelaar, en misschien kan je collega je een paar nieuwe trucs leren.

een goede manier om efficiënt gebruik te maken van uw tijd (en die van hen) is om geà nformeerde vragen te formuleren. Probeer terug te gaan naar de codebase als geheel en erachter te komen de hiaten in uw begrip. Niet alleen zal het hen helpen om een beter idee te krijgen van wat uw probleem is, maar het laat zien dat u het initiatief nam om het probleem eerst zelf op te lossen.

weet wanneer u uw verliezen moet verminderen

als u te veel tijd spendeert om uw voet tussen de deur te krijgen en geen serieuze stap hebt gemaakt in de richting van de implementatie van de functie na het proberen van de bovenstaande stappen, is het misschien de moeite waard om de code om uw functie heen te heractiveren. Geef niet te gemakkelijk op, maar houd ook in gedachten wat uw deadlines zijn en wat uw projectmanager van u verwacht.

Dat gezegd hebbende, zijn er nadelen aan om het zo te doen:

• herschrijven van code kan bugs introduceren, hoewel dit enigszins kan worden omzeild met goede unit testing.
• herschrijven van code kan verborgen functionaliteit verwijderen, hoewel dit ook kan worden omzeild met goede unit tests.
• als u tijd nodig hebt, kan het schrijven van code buiten uw functie in aanvulling op uw functie in feite meer tijdrovend zijn dan er gewoon omheen te bouwen.

alles bij elkaar, Gebruik uw beste oordeel. Er zijn voors en tegens voor beide keuzes, en het is allemaal afhankelijk van uw individuele omstandigheden en projectbudget.

How to deal with legacy code on a psychological level

Photo by Simon Migaj on Unsplash

nu we de technische aspecten van het omgaan met legacy code hebben behandeld, laten we het hebben over hoe ermee om te gaan met behulp van onze soft skills. Immers, ontwikkelaars zijn mensen, niet alleen het coderen van robots, en het omgaan met uitdagende problemen op projecten die creativiteit vereisen en auteurschap kan emotioneel belastend zijn, niet alleen voor u, maar ook voor uw collega ‘ s.

wees nederig en vriendelijk

Dit is iets waarvan ik op schaapachtige wijze zal toegeven dat ik meer moet oefenen. Toen ik voor het eerst werd toegewezen het filter modal project, Ik was vrij vocaal over hoe janky en onaantrekkelijk de code was om te gaan met terwijl de oorspronkelijke auteur van de code zat 15 meter afstand van mij. Ik bedoelde mijn opmerkingen om een grap te zijn, maar achteraf zie ik dat ik arrogant en kwetsend was, en dat ik meer empathisch had moeten zijn.

er zijn veel factoren die ertoe kunnen leiden dat oude code er “off” uitziet, waarmee je rekening moet houden voordat je de auteur begint te bekritiseren of het ergste ervan gaat aannemen (dit is losjes verbonden met de fundamentele attributiefout!).

de oorspronkelijke auteur kan zijn redenen gehad hebben om code te schrijven zoals ze dat deden.

tijdbeperkingen en technologische beperkingen kunnen ertoe leiden dat een persoon code schrijft die werkt maar niet noodzakelijkerwijs de beste Conventie heeft. Als je jezelf in een situatie met niet genoeg tijd, verouderde tools, en een todo lijst van een mijl lang, je waarschijnlijk niet zou schrijven de beste code ofwel!

conventies veranderen.

in oudere Olio Apps projecten gebruikt de conventie voor code enkele aanhalingstekens om strings te declareren, en twee spaties waren gelijk aan één tab. We hadden meerdere kleine React componenten genest in een enkel bestand. In onze huidige conventie gebruiken we dubbele aanhalingstekens en vier spaties, en elke react component, hoe klein ook, leeft in zijn eigen .tsx bestand in de component map. En over een paar jaar, Weet ik zeker dat dat ook zal veranderen.

alle code wordt uiteindelijk legacy

Dit sluit aan bij het vorige punt: uw code wordt uiteindelijk legacy. Als je omhoog de ladder van anciënniteit, nieuwe ontwikkelaars zullen worden ingehuurd op en zal moeten uw oude code te handhaven. Je zou schone, vlekkeloze, droge code kunnen schrijven, maar zodra conventies veranderen of trends veranderen, kunnen die nieuwe ontwikkelaars je code bekijken op dezelfde manier als je de oude code van anderen bekijkt.

wees trots op de kleine successen

Het is niet gemakkelijk om buiten je gebruikelijke conventies te werken; er is een reden voor de enorme schat aan memes en grappen over het omgaan met oude code. Als je ooit een taal buiten je moedertaal hebt geleerd, Weet je hoe het voelt om een woord of term in je tweede taal te vergeten, maar onthoud het in je moedertaal en niet in staat te zijn om over de kloof te vertalen. Hetzelfde geldt voor het veranderen tussen moderne en legacy conventies. Soms duurt het maar een minuut om je positie te herstellen.

Als u succesvol door legacy-code kunt navigeren, toont u uw vermogen om aanpasbaar te zijn, wat een belangrijke vaardigheid is die u ten goede komt bij uw huidige baan en al uw toekomstige banen, of die nu in het technologische veld zijn of niet. Legacy code is de perfecte speeltuin om deze vaardigheid te oefenen.

concluderend:

Gebruik deze tijd om uw eigen code te schrijven

nu u de ervaring hebt gehad om in een oude codebase te werken, moet u er vanaf komen met een beter gevoel van wat u wel en niet leuk vindt in termen van hulpmiddelen en conventies. Dit zijn dingen waarmee je kunt doorgaan in toekomstige projecten, en je beter kunt maken in het herzien van de code van anderen, het aanbieden van opbouwende kritiek, en het geven van mentorschap.

ontwikkel apps voor de gebruiker en de toekomstige Ontwikkelaar

of u nu ervaring hebt met geweldige documentatie en codecommentaren of geen documentatie of codecommentaren, u kunt zien hoe zowel documentatie als commentaren krachtige hulpmiddelen zijn om toekomstige ontwikkelaars te helpen door het project te navigeren. U deelt een gemeenschappelijk doel van het willen van een soepele, functionele, en droge app; het onderhouden van de documentatie en het achterlaten van informatieve code opmerkingen is een goede manier om die kloof te overbruggen.

onthoud dat je code op een dag ook legacy zal zijn

Ik heb dit al een paar keer genoemd, maar het is belangrijk om te herhalen dat je code ook legacy zal zijn, ongeacht hoe droog en ongerept je code en logica zijn.

de belangrijkste afhaalmaaltijd is om flexibel, bescheiden te zijn, en dat je zeker nieuwe trucs kunt leren van oude code.