9 måter å mestre forferdelig kode, fast

Du har fått oppgaven med å implementere en ny funksjon på en gammel kodebase, men koden ser forferdelig ut. Hvordan kan du forstå det så raskt som mulig? Her er flere snarveier for å lære de viktige delene av ny kode uten å gå seg vill i irrelevante detaljer.

som programmerere må vi ofte bli med på nye prosjekter, og kvaliteten på koden kan være over alt. Selv med et organisert team er det en utfordring å holde kodekvaliteten konsistent gjennom et mellomstort til stort prosjekt.

det er derfor forstå dårlig kode raskt kan være en verdifull ferdighet å ha. Det kan hjelpe deg å bli svært produktiv i løpet av kort tid og redusere stress som vanligvis kommer med å være den nye fyren og måtte spille catch-up. Å være i en samtale med en kollega og ikke vite hva den personen snakker om halvparten av tiden, er en forferdelig følelse.

på den annen side er dette en førsteklasses mulighet for å vise din klient eller sjef din verdi, og at du raskt kan få fart og imponere dem. De fleste utviklere tar uker til måneder for å bli veldig produktive med en kodebase de ikke bygde seg selv.

slik mestrer du forferdelig kode raskt.

Be om hjelp. Det er den mest effektive strategien

Andre har allerede lært hvordan koden fungerer, så hvorfor ikke spørre dem om det? Du tror kanskje det gjør at du ser ut som nybegynner, men viser nysgjerrighet kan ha en sterk innvirkning på bildet som en ansatt. Hvis sjefens forventning var at du skulle bli produktiv raskt uten å stille spørsmål, er det en feilvurdering fra hennes side.

Alle tar tid å komme opp til fart. Still spørsmål, og du vil imponere folk som har den rette holdningen for teamarbeid.

i mange tilfeller vil de opprinnelige utviklerne ha gjort merkelige eller uventede beslutninger, og det er her å snakke om koden vil være mye mer verdifull enn å lese den. Dette er enda mer tilfelle hvis dokumentasjonen mangler. Husk at eksisterende utviklere har verdifull prosjektkunnskap som ikke er skrevet hvor som helst.

Lag en liste over begreper som ikke gir mening for deg

det kan være forretningskonsepter som er nye for deg eller som er altfor komplekse. Det er viktig å få avklaring om dem før du prøver å jobbe med kode som håndterer disse konseptene, for å unngå misforståelser som kan ta en stund å finne ut.

det kan også være slik at disse ideene er mislabeled eller representert på en uventet måte i en database. Så unngå å bli stresset over å pakke hjernen din rundt det, og bare gå til kilden og spør dine medarbeidere om det.

i samme retning kan det være moduler, klasser eller enheter som ikke har passende navn. Noter dem. Dårlig navngitte elementer kan føre til stor forvirring, så dokumentere dem tidlig, samt noe annet som vil negativt påvirke din evne til å tenke på hvordan koden fungerer.

Gjør det enkelt å reprodusere feil

ved å legge til kodeversjon og en virtuell maskin som Docker eller Vagrant, vil du i stor grad redusere tiden det tar å reprodusere en feil og teste arbeidet ditt på en ny funksjon.

enhver form for misforståelse om hvordan koden fungerer, kan føre deg ned en vei for å bygge feil ting, enten fordi det du bygger, kanskje allerede er der, og du ikke har sett det, eller fordi ting bare ikke fungerer slik du trodde.

På dette tidspunktet vil Du ha Git-versjonskontroll i prosjektet ditt. På den måten kan du gå tilbake til en stabil utgivelse, eller til og med bare jobbe på separate grener som kan kasseres om nødvendig.

det er også mulig å få større reproduserbarhet Med Git, siden du kan bruke stash til å legge til testing eller feilsøkingskode mens du graver inn i et vanskelig å spore problem.

hvis du vil lære om prosjektets arkitektur, kan du ta på konfigurasjons-og dokumentasjonsoppgaver tidlig.

det samme kan sies om Vm og reproduserbarhet. De har blitt allestedsnærværende for ethvert moderne utviklingsteam, men du vil sikkert løpe inn i prosjekter som ikke bruker dem eller til og med klar til å kjøre i en. Noen ganger er ditt første skritt som et nytt teammedlem å dokumentere trinnene du tok for å få et miljø til å fungere, og til slutt slå disse trinnene til ET VM-oppsettskript.

Bygg et diagram over komponenter

et tankekart over forretningskonsepter, et enhetsrelasjonsdiagram (erd) av databasetabellene, og et enkelt diagram over kodekomponenter kan i stor grad bidra til å redusere smerten ved å forstå ny kode. Husker du ikke hvordan noe fungerer? Hold AKUTTMOTTAKET åpent.

faktisk vil ethvert grafisk verktøy som hjelper deg med å fordøye informasjon raskt og ha en ti tusen fot visning av et prosjekt, være verdifullt. Andre eksempler på verktøy som kan hjelpe deg det er avhengighet grafer, logger og et kart over prosjektets teknologi stabel.

en av de største tidsforbrukerne i utvikling er integrasjonspunktet mellom systemer. Å ha et globalt syn på prosjektlandskapet vil hjelpe deg med å identifisere hvilke integrasjonspunkter som er interessante å undersøke. Det er de stedene som har mest arbeid satt inn i dem, og de fleste bugs.

på den annen side beveger teknologien seg raskt, og det kan være muligheter for å erstatte store deler av kodebasen med mer moderne og riktig integrerte løsninger. Et gammelt rammeverk kan ha utviklet en ny og offisiell måte å løse et problem på, eller et helt nytt bibliotek kan ha blitt utviklet med bedre kompatibilitet i tankene.

Bruk visualiserings-og modelleringsverktøy for å vise det store bildet.

Forbered deg på automatisert testing

før du begynner å bryte ting, er det alltid forsiktig å legge til relevante enhetstester. Problemet med testing og dårlig kode er at dårlig kode vanligvis er tett koblet og vanskelig (om ikke umulig) å teste. Du kan ikke isolere komponenter som er sammenflettet og udelelig.

i disse tilfellene, ta et skritt tilbake og test fra lenger unna. Vanligvis betyr det å gjøre integrasjonstesting, for hvilke det er mange verktøy tilgjengelig. Web apps kan testes mot HTTP-forespørsler, så det er i det minste mulig å verifisere at systemet vil svare på samme måte til de samme inngangene.

Integrasjonstesting har mye verre ytelse enn enhetstester, skjønt. Når du kan, kan du implementere enhetstester slik at du kan få raskere tilbakemelding på kodeendringer. Hvis det ikke er mulig, velger du funksjonell eller til og med integrasjonstesting.

Dette trinnet bør kaste lys over de delene av koden som trenger arbeid. Hvis det er en stor mengde tett koblet kode, er det et godt mål for refactoring etter at integrasjonstester er gjort, og deretter for enhetstesting senere.

Identifiser uvanlige eller utilstrekkelige kodingsstrategier

Det er på tide å begynne å gjøre noen refactoring, men hvor begynner du?

Vanligvis er det beste stedet hvor ting ser rart ut, eller hvor utvikling beste praksis ikke har blitt fulgt. For webutvikling kan det bety fat-kontrollere med tett koblet modellkode.

Husk at de samme strategiene kan være i bruk andre steder. Så hvis du for eksempel identifiserer at fat-kontrollere er til stede, er det sannsynlig at tidligere utviklere ikke forsøkte å ha tynne kontroller. Du kan forvente å se det samme problemet i andre kontroller også, siden det reflekterte stilen eller manglene i utviklingsprosessen før nå.

til å begynne med jobber du med en liten oppgave

Å Fikse en liten feil på en funksjon som er konseptuelt enkel, vil være veldig opplysende og vil hjelpe deg til å føle deg produktiv fra starten.

Dette er en lignende ide Som Andy Hunt og Dave Thomas kaller “tracer bullets” i Pragmatic Programmerer. Den underliggende logikken er den samme: Arbeid på noe ende-til-ende for å bevise for deg selv at det er mulig, og deretter gradvis forbedre det første arbeidet.

“tracer bullet” tilnærming. Kreditt:Pragmatisk Programmerer

et godt eksempel på hva slags enkel forbedring du kan gjøre er å ta små refactoring trinn med enkel kode. Identifiser en vanlig programmeringspraksis som ikke følges, og bruk den.

en av mine favoritter for dette er un-nesting betingede blokker. Så i stedet for å ha flere if-if-if-blokker, en i den andre, negere den første og returnere, og gjør det samme for alle valideringstypekontroller du kan finne. Dette kan være så enkelt som å invertere en “hvis”-sjekk og flytte noen kode rundt, så risikoen er nesten ikke-eksisterende, og den flate koden blir lettere å lese.

sørg for å jobbe først med refactoring-funksjoner som er enkle å teste, fordi selv om endringene er lavrisiko, er det alltid en god ide å kunne validere koden din før du sender den til produksjon.

Kom deg på kjent grunn før du takler kritisk kode

lær alltid hvordan prosjektet er satt opp først, og bare da dykk inn i arkitektonisk side. De mest kritiske delene av virksomheten og integrasjonskoden er de vanskeligste å forstå og endre. Unngå å komme i trøbbel tidlig.

som en generell regel, unngå forretningsproblemer som vil kreve at du vet mer enn du for øyeblikket gjør om prosjektet, eller om forretningssiden. Det betyr vanligvis å holde seg borte fra transaksjons -, betalings-eller matte-tung kode til den begynner å bli kjent.

når du er produktiv, er komfortabel med kodingsstilen for prosjektet, og har ingen problemer med å fikse enkle problemer, er det på tide å jobbe med de vanskeligere tingene—men ikke før.

selv om det er noe haster for å fikse betalingsproblemer, kan den typen oppgave være utrolig risikabelt. En feil det kan koste prosjektet dyrt, og det vil være på deg også. Absolutt nekte å jobbe med høyrisikooppgaver tidlig hvis det er mulig.

hvordan håndtere en ukjent tech stack

for det siste punktet, et vanlig problem jeg har kjørt inn er at hvert nytt prosjekt vanligvis inneholder noen teknologi som jeg ikke er kjent med.

når det skjer, har jeg et par strategier som hjelper meg med å få fart raskt. Den åpenbare veien for læring er å lese dokumentasjon og bli kjent med den nye teknologien. Men mens du vil lære mye om struktur, vil den banen ikke hjelpe deg med å lære hjørnesaker, som vanligvis kommer med erfaring. (“Corner case” er et teknisk begrep som refererer til en situasjon som oppstår utenfor normale driftsparametere.)

en måte å øke hastigheten på denne prosessen med å få erfaring er å ta spørsmålsbaserte ressurser som Stack Overflow og Quora og bare lese gjennom dem som en bok. Finn de mest populære spørsmålene om biblioteket du lærer og se hva slags problemer andre mennesker vanligvis støter på. Du kommer ikke nødvendigvis til å løpe inn i dem selv, men bare å vite hva som er mulig, er som å skinne et sterkt lys på tankekartet ditt over de nye ideene.

Leverage Stack Overflow spørsmål for å få erfaring raskt. Kreditt: Stack Overflow

for en mer målrettet tilnærming finner du informasjon om biblioteksfunksjoner som brukes spesielt i det nye prosjektet. Se på de som er nye for deg og lær dem på forhånd, før du må røre den koden i det hele tatt.

Del dine ideer