9 måder at mestre forfærdelig kode, hurtig

du har fået til opgave at implementere en ny funktion på en gammel kodebase, men koden ser forfærdelig ud. Hvordan kan du forstå det så hurtigt som muligt? Her er flere genveje, der hjælper med at lære de vigtige dele af ny kode uden at gå tabt i de irrelevante detaljer.

som programmører er vi ofte nødt til at deltage i nye projekter, og kvaliteten af koden kan være overalt. Selv med et organiseret team er det en udfordring at holde kodekvaliteten ensartet gennem et mellemstort til stort projekt.

derfor kan forståelse af dårlig kode hurtigt være en værdifuld færdighed at have. Det kan hjælpe dig med at blive meget produktiv på kort tid og reducere den stress, der normalt følger med at være den nye fyr og skulle spille indhentning. At være i en samtale med en kollega og ikke vide, hvad den person taler om halvdelen af tiden, er en frygtelig følelse.

på den anden side er dette en førsteklasses mulighed for at vise din klient eller chef dit værd, og at du hurtigt kan komme op i fart og imponere dem. De fleste udviklere tager uger til måneder for at blive virkelig produktive med en kodebase, de ikke byggede sig selv.

sådan mestrer du forfærdelig kode hurtigt.

Bed om hjælp. Det er den mest effektive strategi

andre mennesker har allerede lært, hvordan koden fungerer, så hvorfor ikke spørge dem om det? Du tror måske, at det får dig til at ligne nybegynderen, men at vise nysgerrighed kan have en stærk indflydelse på dit image som medarbejder. Hvis din chefs forventning var, at du skulle blive produktiv hurtigt uden at stille spørgsmål, er det en forkert vurdering fra hendes side.

alle tager tid at komme op i fart. Stil spørgsmål, og du vil imponere de mennesker, der har den rigtige holdning til samarbejde.

i mange tilfælde vil de originale udviklere have taget mærkelige eller uventede beslutninger, og det er her at tale om koden vil være meget mere værdifuld end at læse den. Dette er endnu mere tilfældet, hvis dokumentationen mangler. Husk, at eksisterende udviklere har værdifuld projektviden, der ikke er skrevet overalt.

lav en liste over begreber, der ikke giver mening for dig

der kan være forretningskoncepter, der er nye for dig, eller som er alt for komplekse. Det er vigtigt at få afklaring om dem, før du prøver at arbejde på kode, der håndterer disse begreber, for at undgå misforståelser, der kan tage et stykke tid at finde ud af.

det kan endda være tilfældet, at disse ideer er fejlagtigt eller repræsenteret på en uventet måde i en database. Så undgå at blive stresset over at indpakke din hjerne omkring det, og bare gå til kilden og spørg dine kolleger om det.

på samme måde kan der være moduler, klasser eller enheder, der ikke har passende navne. Noter dem. Dårligt navngivne elementer kan føre til stor forvirring, så dokumentere dem tidligt såvel som alt andet, der vil påvirke din evne til at tænke over, hvordan koden fungerer negativt.

gør det nemt at gengive fejl

ved at tilføje kodeversionering og en virtuel maskine som Docker eller Vagrant reducerer du i høj grad den tid, det tager at gengive en fejl og teste dit arbejde på en ny funktion.

enhver form for misforståelse om, hvordan koden fungerer, kan føre dig ned ad en sti til at bygge den forkerte ting, enten fordi det, du bygger, måske allerede er der, og du ikke har set det, eller fordi ting bare ikke fungerer som du troede.

på dette tidspunkt vil du have Git-versionskontrol i dit projekt. På den måde kan du gå tilbage til en stabil frigivelse eller endda bare arbejde på separate grene, der kan kasseres, hvis det er nødvendigt.

det er endda muligt at opnå større Reproducerbarhed med Git, da du kan bruge stash til at tilføje test eller debugging kode, mens du graver ind i et svært at spore problem.

hvis du vil vide mere om dit projekts arkitektur, skal du udføre konfigurations-og dokumentationsopgaver tidligt.

det samme kan siges om VM ‘ er og reproducerbarhed. De er blevet allestedsnærværende for ethvert moderne udviklingsteam, men du vil helt sikkert løbe ind i projekter, der ikke bruger dem eller endda klar til at køre inde i et. Nogle gange er dit første skridt som nyt teammedlem at dokumentere de trin, du tog for at få et miljø til at fungere, og til sidst omdanne disse trin til et VM-opsætningsskript.

Byg et diagram over komponenter

et tankekort over forretningskoncepter, et entity-relationel diagram (ERD) af databasetabellerne og et simpelt diagram over kodekomponenter kan i høj grad bidrage til at reducere smerten ved at forstå ny kode. Kan du ikke huske, hvordan noget fungerer? Hold den ERD åben.

faktisk vil ethvert grafisk værktøj, der hjælper dig med at fordøje information hurtigt og have en ti tusind fods visning af et projekt, være værdifuldt. Andre eksempler på værktøjer, der kan hjælpe dig der er afhængighedsgrafer, logfiler og et kort over projektets teknologistak.

en af de største tidsforbrugere i udvikling er integrationspunktet mellem systemer. At have et globalt overblik over projektlandskabet hjælper dig med at identificere, hvilke integrationspunkter der er interessante at undersøge. Det er de pletter, der har mest arbejde lagt i dem, og de fleste fejl.

på den anden side bevæger teknologien sig hurtigt, og der kan være muligheder for at erstatte store dele af kodebasen med mere moderne og korrekt integrerede løsninger. En gammel ramme kunne have udviklet en ny og officiel måde at løse et problem på, eller et helt nyt bibliotek kunne have været udviklet med bedre kompatibilitet i tankerne.

brug visualiserings-og modelleringsværktøjer til at se det store billede.

forbered dig på automatiseret test

før du begynder at bryde ting, er det altid klogt at tilføje relevante enhedstest. Problemet med test og dårlig kode er, at dårlig kode normalt er tæt koblet og hård (hvis ikke umulig) at teste. Du kan ikke isolere komponenter, der er sammenflettet og udelelige.

i disse tilfælde skal du tage et skridt tilbage og teste længere væk. Normalt betyder det at udføre integrationstest, som der er mange tilgængelige værktøjer til. Internet-apps kan testes mod HTTP-anmodninger, så det er i det mindste muligt at kontrollere, at systemet reagerer på samme måde på de samme input.

integrationstest har dog meget dårligere ydeevne end enhedstest. Når du kan, skal du implementere enhedstest, så du kan få hurtigere feedback på kodeændringer. Hvis det ikke er muligt, skal du vælge funktionel eller endda integrationstest.

dette trin skal kaste lys over de dele af koden, der har brug for arbejde. Hvis der er en stor mængde tæt koblet kode, er det et godt mål for refactoring, efter at integrationstest er udført, og derefter til enhedstest senere.

Identificer usædvanlige eller utilstrækkelige kodningsstrategier

det er tid til at begynde at lave noget refactoring, men hvor starter du?

normalt er det bedste sted, hvor tingene ser underlige ud, eller hvor udviklingspraksis ikke er blevet fulgt. Til internetudvikling kan det betyde fede controllere med tæt koblet modelkode.

Husk, at de samme strategier kan være i brug andre steder. Så hvis du for eksempel identificerer, at fat-controllere er til stede, er det sandsynligt, at tidligere udviklere ikke forsøgte at have tynde controllere. Du kan også forvente at se det samme problem i andre controllere, da det afspejlede stilen eller manglerne i udviklingsprocessen før nu.

først skal du arbejde på en lille opgave

at rette en lille fejl på en funktion, der er konceptuelt enkel, vil være meget oplysende og hjælpe dig med at føle dig produktiv fra starten.

dette er en lignende ide som Andy Hunt og Dave Thomas kalder “tracer bullets” i den pragmatiske programmør. Den underliggende logik er den samme: arbejde på noget end-to-end for at bevise for dig selv, at det er muligt, og derefter gradvist forbedre det oprindelige arbejde.

den “tracer bullet” tilgang. Kredit: den pragmatiske programmør

et godt eksempel på den slags enkle forbedring, du kan gøre, er at tage små refactoring trin med simpel kode. Identificer en fælles programmeringspraksis, der ikke følges, og anvend den.

en af mine favoritter til dette er un-nesting betingede blokke. Så i stedet for at have flere if-if-blokke, den ene inde i den anden, negerer den første og vender tilbage, og gør det samme for alle valideringstypekontroller, du kan finde. Dette kan være så simpelt som at vende en “hvis” check og flytte noget kode rundt, så risikoen er næsten ikke-eksisterende, og den flade kode bliver lettere at læse.

sørg for at arbejde først på refactoring-funktioner, der er lette at teste, for selvom ændringerne er lavrisiko, er det altid en god ide at kunne validere din kode, før du sender den til produktion.

kom på velkendt grund, før du tackler kritisk kode

lær altid, hvordan projektet er oprettet først, og dyk først ned i den arkitektoniske side. De mest kritiske stykker af business og integration kode er de sværeste at forstå og ændre. Undgå at komme i problemer tidligt.

undgå som hovedregel forretningsproblemer, der kræver, at du ved mere, end du i øjeblikket gør om projektet eller om forretningssiden. Det betyder normalt at holde sig væk fra transaktions -, betalinger eller matematiktung kode, indtil den begynder at blive kendt.

når du er produktiv, har det godt med kodestilen til projektet og ikke har problemer med at løse enkle problemer, er det tid til at arbejde på de hårdere ting—men ikke før.

selv hvis der er en vis haster med at løse betalingsspørgsmål, for eksempel, kan den slags opgave være utroligt risikabel. En fejl der kan koste projektet dyrt, og det vil også være på dig. Absolut nægter at arbejde på højrisikoopgaver tidligt, hvis det overhovedet er muligt.

Sådan håndteres en ukendt tech stack

for det sidste punkt er et almindeligt problem, jeg har stødt på, at hvert nyt projekt normalt indeholder noget teknologi, som jeg ikke er bekendt med.

når det sker, har jeg et par strategier, der hjælper mig med at komme hurtigt op. Den oplagte vej til læring er at læse dokumentation og blive fortrolig med den nye teknologi. Men mens du vil lære meget om struktur, vil denne sti ikke hjælpe dig med at lære hjørnesagerne, som typisk kommer med erfaring. (“Hjørnesag” er et teknisk udtryk, der henviser til en situation, der opstår uden for normale driftsparametre.)

en måde at fremskynde denne proces med at få erfaring er at tage spørgsmålsbaserede ressourcer som stakoverløb og kvora og bare læse dem som en bog. Find de mest populære spørgsmål om det Bibliotek, du lærer, og se, hvilken slags problemer andre mennesker typisk støder på. Du vil ikke nødvendigvis løbe ind i dem selv, men bare at vide, hvad der er muligt, er som at skinne et stærkt lys på dit tankekort over de nye ideer.

gearing stak overløb spørgsmål at få erfaring hurtigt. Kredit: stak overløb

for en mere målrettet tilgang, finde oplysninger om bibliotek funktioner, der bruges i dit nye projekt specifikt. Se på dem, der er nye for dig, og lær dem på forhånd, før du overhovedet skal røre ved den kode.

Del dine ideer