9 manieren om vreselijke code onder de knie te krijgen, fast

je hebt de taak gekregen om een nieuwe functie te implementeren op een oude codebase, maar de code ziet er verschrikkelijk uit. Hoe kun je het zo snel mogelijk begrijpen? Hier zijn verschillende snelkoppelingen om te helpen de belangrijke delen van de nieuwe code te leren zonder te verdwalen in de irrelevante details.

als programmeurs moeten we vaak deelnemen aan nieuwe projecten, en de kwaliteit van de code kan overal zijn. Zelfs met een georganiseerd team is het een uitdaging om de kwaliteit van de code consistent te houden gedurende een middelgroot tot groot project.

daarom kan het snel begrijpen van slechte code een waardevolle vaardigheid zijn. Het kan u helpen zeer productief te worden in een korte tijd en het verminderen van de stress die meestal wordt geleverd met het zijn de nieuwe man en het hebben om te spelen catch-up. In gesprek zijn met een collega en de helft van de tijd niet weten waar die persoon het over heeft, is een vreselijk gevoel.

aan de andere kant is dit een uitgelezen kans om uw cliënt of baas uw waarde te laten zien en dat u snel kunt bijwerken en indruk op hen kunt maken. De meeste ontwikkelaars nemen weken tot maanden om echt productief te worden met een codebase die ze niet zelf hebben gebouwd.

hier is hoe vreselijke code snel onder de knie te krijgen.

vraag om hulp. Het is de meest efficiënte strategie

andere mensen hebben al geleerd hoe de code werkt, dus waarom vragen ze er niet naar? Je zou denken dat het maakt je eruit als de newbie, maar het tonen van nieuwsgierigheid kan een sterke impact hebben op uw imago als werknemer. Als je baas verwachtte dat je snel productief zou worden zonder vragen te stellen, dan is dat een verkeerde inschatting van haar kant.

iedereen heeft tijd nodig om op snelheid te komen. Stel vragen en je zult indruk maken op de mensen die de juiste houding hebben voor teamwork.

in veel gevallen zullen de oorspronkelijke ontwikkelaars vreemde of onverwachte beslissingen hebben genomen, en dat is waar praten over de code veel waardevoller zal zijn dan het lezen ervan. Dit is des te meer het geval als de documentatie ontbreekt. Vergeet niet, bestaande ontwikkelaars hebben waardevolle projectkennis die nergens is geschreven.

Maak een lijst met concepten die u niet begrijpt

er kunnen bedrijfsconcepten zijn die nieuw voor u zijn of die te complex zijn. Het is belangrijk om duidelijkheid te krijgen over hen voordat u probeert te werken aan code die deze concepten behandelt, om misverstanden die een tijdje duren om erachter te komen te voorkomen.

het kan zelfs zo zijn dat deze ideeën verkeerd zijn gelabeld of op een onverwachte manier worden weergegeven in een database. Dus vermijd stress over het wikkelen van je hersenen rond dat, en ga gewoon naar de bron en vraag je collega ‘ s over.

in dezelfde geest kunnen er modules, klassen of entiteiten zijn die geen passende namen hebben. Noteer ze. Slecht benoemde elementen kunnen leiden tot grote verwarring, dus documenteer ze vroeg, evenals alles wat een negatieve invloed heeft op uw vermogen om na te denken over hoe de code werkt.

Maak het gemakkelijk om bugs

te reproduceren door code versiebeheer en een virtuele machine zoals Docker of Vagrant toe te voegen, zult u de tijd die nodig is om een bug te reproduceren en om uw werk te testen op een nieuwe functie aanzienlijk verminderen.

elke vorm van misverstand over hoe de code werkt kan je leiden naar een pad van het bouwen van het verkeerde ding, ofwel omdat wat je bouwt er al zou kunnen zijn en je hebt het niet gezien, of omdat dingen gewoon niet werken zoals je dacht.

op dit moment wil je Git versiebeheer in je project hebben. Op die manier zul je in staat zijn om terug te gaan naar een stabiele release, of zelfs gewoon te werken aan aparte branches die kunnen worden weggegooid indien nodig.

het is zelfs mogelijk om een grotere reproduceerbaarheid te verkrijgen met Git, omdat je de stash kunt gebruiken om test-of debugcode toe te voegen terwijl je in een moeilijk te volgen probleem graaft.

om meer te weten te komen over de architectuur van uw project, neemt u in een vroeg stadium de configuratie-en documentatietaken aan.

hetzelfde kan worden gezegd over VMs en reproduceerbaarheid. Ze zijn alomtegenwoordig geworden voor elk modern ontwikkelingsteam, maar je zult zeker projecten tegenkomen die ze niet gebruiken of zelfs klaar zijn om in één te draaien. Soms is je eerste stap als nieuw teamlid het documenteren van de stappen die je hebt genomen om een omgeving werkend te krijgen, en uiteindelijk deze stappen om te zetten in een VM-installatiescript.

Maak een diagram van componenten

een mindmap van bedrijfsconcepten, een entity-relational diagram (ERD) van de databasetabellen en een eenvoudig diagram van code-componenten kunnen de pijn van het begrijpen van nieuwe code aanzienlijk helpen verminderen. Weet je niet meer hoe iets werkt? Hou die eerste hulp open.

in feite is elk grafisch hulpmiddel dat u helpt om informatie snel te verwerken en een beeld van een project te krijgen, waardevol. Andere voorbeelden van tools die u kunnen helpen zijn afhankelijkheidsgrafieken, logboeken en een kaart van de technologiestack van het project.

een van de grootste consumenten in ontwikkeling is het integratiepunt tussen systemen. Een globale visie op het projectlandschap zal u helpen te bepalen welke integratiepunten interessant zijn om te onderzoeken. Dat zijn de plekken waar het meeste werk in zit, en de meeste bugs.

anderzijds gaat de technologie snel en zouden er mogelijkheden kunnen zijn om grote delen van de codebase te vervangen door modernere en goed geïntegreerde oplossingen. Een oud framework zou een nieuwe en officiële manier kunnen hebben ontwikkeld om een probleem op te lossen, of een geheel nieuwe bibliotheek zou kunnen zijn ontwikkeld met een betere compatibiliteit in het achterhoofd.

gebruik hulpmiddelen voor visualisatie en modellering om het grote geheel te bekijken.

Prepare for automated testing

voordat u dingen breekt, is het altijd verstandig om relevante unit tests toe te voegen. Het probleem met testen en slechte code is dat slechte code meestal strak gekoppeld is en moeilijk (zo niet onmogelijk) te testen. Je kunt componenten die met elkaar verweven en ondeelbaar zijn niet isoleren.

in die gevallen een stap terug doen en van verder weg testen. Meestal betekent dat het doen van integratie testen, waarvoor er veel tools beschikbaar zijn. Web apps kunnen worden getest op HTTP-verzoeken, dus het is op zijn minst mogelijk om te controleren of het systeem op dezelfde manier zal reageren op dezelfde ingangen.

integratie testen heeft echter veel slechtere prestaties dan unit tests. Implementeer eenheidstests wanneer u kunt, zodat u sneller feedback kunt krijgen over codewijzigingen. Als dat niet mogelijk is, kies dan voor functionele of zelfs integratie testen.

deze stap moet enig licht werpen op de delen van de code die moeten worden bewerkt. Als er een grote hoeveelheid strak gekoppelde code is, is dat een goed doel voor refactoring nadat integratietests zijn gedaan, en dan voor unit testen later.

ongebruikelijke of inadequate coderingsstrategieën identificeren

het is tijd om wat refactoring te doen, maar waar begint u?

meestal is de beste plaats waar dingen er raar uitzien, of waar de beste ontwikkelingspraktijken niet zijn gevolgd. Voor webontwikkeling, zou dat vette controllers met strak gekoppelde modelcode kunnen betekenen.

Houd er rekening mee dat dezelfde strategieën elders kunnen worden gebruikt. Dus als je bijvoorbeeld vaststelt dat fat-controllers aanwezig zijn, dan is het waarschijnlijk dat eerdere ontwikkelaars niet hebben geprobeerd om dunne controllers te hebben. U kunt verwachten om hetzelfde probleem te zien in andere controllers ook, omdat dat weerspiegeld de stijl of tekortkomingen van het ontwikkelingsproces voor nu.

in het begin zal werken aan een kleine taak

het oplossen van een kleine bug op een functie die conceptueel eenvoudig is, zeer verhelderend zijn en zal u helpen u vanaf het begin productief te voelen.

Dit is een soortgelijk idee als wat Andy Hunt en Dave Thomas “tracer bullets” noemen in de Pragmatic Programmer. De onderliggende logica is hetzelfde: werk aan iets end-to-end om jezelf te bewijzen dat het mogelijk is, en verbeter dan geleidelijk aan dat eerste werk.

de “tracer bullet” – benadering. Credit: De pragmatische programmeur

een goed voorbeeld van het soort eenvoudige verbetering dat u kunt maken is het nemen van kleine refactoring stappen met eenvoudige code. Identificeer een gemeenschappelijke programmeerpraktijk die niet wordt gevolgd, en pas deze toe.

een van mijn favorieten hiervoor is het ongedaan maken van voorwaardelijke blokken. Dus in plaats van het hebben van meerdere if-if-if blokken, een in de andere, negate de eerste en return, en doe hetzelfde voor alle validation-type controles die u kunt vinden. Dit kan zo eenvoudig zijn als het omkeren van een” als ” controle en het verplaatsen van een aantal code rond, dus het risico is bijna onbestaande en de platte code zal gemakkelijker te lezen.

zorg ervoor dat u eerst werkt aan refactoring-functies die gemakkelijk te testen zijn, want hoewel de wijzigingen een laag risico inhouden, is het altijd een goed idee om uw code te kunnen valideren voordat u deze naar productie stuurt.

ga op vertrouwd terrein voordat u kritische code

aanpakt, leer altijd eerst hoe het project wordt opgezet en duik pas daarna in de architectonische kant. De meest kritische onderdelen van business en integratie code zijn het moeilijkst te begrijpen en te wijzigen. Vermijd het krijgen van in de problemen vroeg op.

in het algemeen dient u zakelijke kwesties te vermijden waarbij u meer over het project of over de zakelijke kant moet weten dan momenteel het geval is. Dat betekent meestal om weg te blijven van transacties, betalingen of wiskunde-zware code totdat het begint om bekende grond te worden.

Als u productief bent, vertrouwd bent met de codeerstijl voor het project en geen problemen hebt om eenvoudige problemen op te lossen, is het tijd om aan de moeilijkere dingen te werken—maar niet eerder.

zelfs als er enige urgentie is om bijvoorbeeld betalingsproblemen op te lossen, kan dit soort taak ongelooflijk riskant zijn. Een fout daar kan het project duur komen te staan, en dat is ook jouw schuld. Absoluut weigeren om te werken aan risicovolle taken vroeg op indien mogelijk.

hoe om te gaan met een onbekende tech stack

voor het laatste punt is een veel voorkomend probleem dat ik tegenkwam dat elk nieuw project meestal een technologie bevat die ik niet ken.

als dat gebeurt, heb ik een paar strategieën die me helpen snel op snelheid te komen. De voor de hand liggende weg om te leren is het lezen van documentatie en vertrouwd raken met de nieuwe technologie. Maar terwijl je veel over structuur leert, zal dat pad je niet helpen om de hoekgevallen te leren, die meestal met ervaring komen. (“Corner case” is een technische term die verwijst naar een situatie die zich buiten de normale bedrijfsparameters voordoet.)

een manier om dit proces van het opdoen van ervaring te versnellen is door op vragen gebaseerde bronnen zoals Stack Overflow en Quora te nemen en ze gewoon door te lezen als een boek. Vind de meest populaire vragen over de bibliotheek die je aan het leren bent en zie wat voor soort problemen andere mensen meestal tegenkomen. Je zult ze niet per se zelf tegenkomen, maar gewoon weten wat er mogelijk is, is als een helder licht schijnen op je Mindmap van die nieuwe ideeën.

gebruik Stack Overflow vragen om snel ervaring op te doen. Credit: Stack Overflow

voor een meer gerichte aanpak, vindt u informatie over bibliotheekfuncties die specifiek in uw nieuwe project worden gebruikt. Kijk naar degenen die nieuw voor je zijn en leer ze van tevoren, voordat je die code helemaal moet aanraken.

deel uw ideeën