9 sätt att behärska hemsk kod, snabb

du har fått uppgiften att implementera en ny funktion på en gammal kodbas, men koden ser hemsk ut. Hur kan du förstå det så snabbt som möjligt? Här är flera genvägar för att lära sig de viktiga delarna av ny kod utan att gå vilse i de irrelevanta detaljerna.

som programmerare måste vi ofta gå med i nya projekt, och kvaliteten på koden kan vara överallt. Även med ett organiserat team är det en utmaning att hålla kodkvaliteten konsekvent under ett medelstort till stort projekt.

det är därför att förstå dålig kod snabbt kan vara en värdefull färdighet att ha. Det kan hjälpa dig att bli mycket produktiv på kort tid och minska den stress som vanligtvis kommer med att vara den nya killen och behöva spela catch-up. Att vara i en konversation med en medarbetare och inte veta vad den personen pratar om halva tiden är en hemsk känsla.

å andra sidan är detta ett utmärkt tillfälle för att visa din klient eller chef ditt värde och att du snabbt kan komma igång och imponera på dem. De flesta utvecklare tar veckor till månader för att bli riktigt produktiva med en kodbas som de inte byggde själva.

så här behärskar du hemsk kod snabbt.

be om hjälp. Det är den mest effektiva strategin

andra människor har redan lärt sig hur koden fungerar, så varför inte fråga dem om det? Du kanske tror att det får dig att se ut som nybörjaren, men att visa nyfikenhet kan ha en stark inverkan på din bild som anställd. Om din chefs förväntan var att du skulle bli produktiv snabbt utan att ställa frågor, är det en felbedömning från hennes sida.

alla tar tid att komma igång. Ställ frågor, och du kommer att imponera på de människor som har rätt attityd för lagarbete.

i många fall kommer de ursprungliga utvecklarna att ha fattat konstiga eller oväntade beslut, och det är där att prata om koden kommer att vara mycket mer värdefull än att läsa den. Detta är ännu mer fallet om dokumentationen saknas. Kom ihåg att befintliga utvecklare har värdefull projektkunskap som inte skrivs någonstans.

gör en lista över begrepp som inte är meningsfulla för dig

det kan finnas affärskoncept som är nya för dig eller som är alltför komplexa. Det är viktigt att få förtydligande om dem innan du försöker arbeta med kod som hanterar dessa begrepp, för att undvika missförstånd som kan ta ett tag att räkna ut.

det kan till och med vara så att dessa ideer är felmärkta eller representerade på ett oväntat sätt i en databas. Så undvik att bli stressad över att förpacka din hjärna runt det, och gå bara till källan och fråga dina medarbetare om det.

på samma sätt kan det finnas moduler, klasser eller enheter som inte har lämpliga namn. Anteckna dem. Dåligt namngivna element kan leda till stor förvirring, så dokumentera dem tidigt, liksom allt annat som negativt påverkar din förmåga att tänka på hur koden fungerar.

gör det enkelt att reproducera buggar

genom att lägga till kodversionering och en virtuell maskin som Docker eller Vagrant, kommer du att minska tiden det tar att reproducera en bugg och testa ditt arbete på en ny funktion.

varje form av missförstånd om hur koden fungerar kan leda dig ner på en väg att bygga fel sak, antingen för att det du bygger kanske redan finns där och du inte har sett det, eller för att saker bara inte fungerar som du trodde.

vid denna tidpunkt vill du ha Git-versionskontroll i ditt projekt. På så sätt kan du gå tillbaka till en stabil release, eller till och med bara arbeta på separata grenar som kan kasseras om det behövs.

det är även möjligt att få större Reproducerbarhet med Git, eftersom du kan använda stashen för att lägga till test-eller felsökningskod medan du gräver i ett svårt att spåra problem.

för att lära dig mer om projektets arkitektur, ta på dig konfigurations-och dokumentationsuppgifter tidigt.

detsamma kan sägas om VM och reproducerbarhet. De har blivit allestädes närvarande för alla moderna utvecklingsteam, men du kommer säkert att stöta på projekt som inte använder dem eller ens redo att köra inuti en. Ibland är ditt första steg som ny teammedlem att dokumentera de steg du tog för att få en miljö att fungera och så småningom förvandla dessa steg till ett VM-installationsskript.

Bygg ett diagram över komponenter

en Tankekarta över affärskoncept, ett entitet-relationsdiagram (ERD) i databastabellerna och ett enkelt diagram över kodkomponenter kan i hög grad bidra till att minska smärtan att förstå ny kod. Kommer du inte ihåg hur något fungerar? Håll ERD öppen.

faktum är att alla grafiska verktyg som hjälper dig att smälta information snabbt och ha en tiotusen fotvy av ett projekt kommer att vara värdefulla. Andra exempel på verktyg som kan hjälpa dig det finns beroende grafer, loggar och en karta över projektets teknik stack.

en av de största tidskonsumenterna i utveckling är integrationspunkten mellan system. Att ha en global bild av projektlandskapet hjälper dig att identifiera vilka integrationspunkter som är intressanta att undersöka. Det är de fläckar som har mest arbete i dem, och de flesta buggar.

å andra sidan går tekniken snabbt och det kan finnas möjligheter att ersätta stora delar av kodbasen med modernare och korrekt integrerade lösningar. En gammal ram kan ha utvecklat ett nytt och officiellt sätt att lösa ett problem, eller ett helt nytt bibliotek kunde ha utvecklats med bättre kompatibilitet i åtanke.

använd visualiserings-och modelleringsverktyg för att se helheten.

Förbered dig för automatiserad testning

innan du börjar bryta saker är det alltid klokt att lägga till relevanta enhetstester. Problemet med testning och dålig kod är att dålig kod vanligtvis är tätt kopplad och hård (om inte omöjlig) att testa. Du kan inte isolera komponenter som är sammanflätade och odelbara.

i dessa fall, ta ett steg tillbaka och testa från längre bort. Vanligtvis innebär det att göra integrationstestning, för vilka det finns många verktyg tillgängliga. Webbappar kan testas mot HTTP-förfrågningar, så det är åtminstone möjligt att verifiera att systemet svarar på samma sätt på samma ingångar.

Integrationstestning har dock mycket sämre prestanda än enhetstester. När du kan, implementera enhetstester så att du kan få snabbare feedback om kodändringar. Om det inte är möjligt, välj sedan funktionell eller till och med integrationstestning.

detta steg bör belysa de delar av koden som behöver arbete. Om det finns en stor mängd tätt kopplad kod, är det ett bra mål för refactoring efter att integrationstester har gjorts, och sedan för enhetstestning senare.

identifiera ovanliga eller otillräckliga kodningsstrategier

det är dags att börja göra lite refactoring, men var börjar du?

vanligtvis är det bästa stället där saker ser konstiga ut, eller där bästa praxis för utveckling inte har följts. För webbutveckling kan det innebära fettkontroller med tätt kopplad modellkod.

Tänk på att samma strategier kan användas någon annanstans. Så om du till exempel identifierar att fat controllers är närvarande, är det troligt att tidigare utvecklare inte försökte ha tunna controllers. Du kan förvänta dig att se samma problem i andra kontroller också, eftersom det återspeglade stilen eller bristerna i utvecklingsprocessen tidigare.

först arbetar du med en liten uppgift

att fixa ett litet fel på en funktion som är konceptuellt enkel kommer att vara mycket upplysande och hjälper dig att känna dig produktiv från början.

Detta är en liknande uppfattning som Andy Hunt och Dave Thomas kallar “tracer bullets” i den pragmatiska programmeraren. Den underliggande logiken är densamma: arbeta på något från början till slut för att bevisa för dig själv att det är möjligt, och sedan gradvis förbättra det ursprungliga arbetet.

“tracer bullet” – metoden. Kredit: den pragmatiska programmeraren

ett bra exempel på den typ av enkel förbättring du kan göra är att ta små refactoring steg med enkel kod. Identifiera en gemensam programmeringspraxis som inte följs och tillämpa den.

en av mina favoriter för detta är un-nesting villkorliga block. Så istället för att ha flera if-if-if-block, en inuti den andra, negerar den första och returnerar, och gör detsamma för alla valideringskontroller du kan hitta. Detta kan vara så enkelt som att invertera en” if ” -kontroll och flytta lite kod runt, så risken är nästan obefintlig och den platta koden blir lättare att läsa.

var noga med att arbeta först med refactoring-funktioner som är lätta att testa, för även om ändringarna är låga risker är det alltid bra att kunna validera din kod innan du skickar den till produktion.

gå på bekant mark innan du tar itu med kritisk kod

lär dig alltid hur projektet ställs in först och först sedan dyka in i den arkitektoniska sidan. De mest kritiska delarna av affärs-och integrationskoden är de svåraste att förstå och modifiera. Undvik att komma i trubbel tidigt.

undvik som regel affärsproblem som kräver att du vet mer än du för närvarande gör om projektet eller om affärssidan. Det betyder vanligtvis att hålla sig borta från transaktions -, betalningar eller matematisk tung kod tills den börjar bli bekant.

när du är produktiv, är bekväm med kodningsstilen för projektet och inte har några problem med att fixa enkla problem är det dags att arbeta med de hårdare sakerna—men inte tidigare.

även om det finns en viss brådska för att fastställa betalningsfrågor, till exempel, den typen av uppgift kan vara oerhört riskabelt. Ett misstag där kan kosta projektet dyrt, och det kommer också att vara på dig. Absolut vägrar att arbeta med högriskuppgifter tidigt om det alls är möjligt.

hur man hanterar en okänd teknisk stack

för den sista punkten är ett vanligt problem jag har stött på att varje nytt projekt vanligtvis innehåller någon teknik som jag inte är bekant med.

när det händer har jag ett par strategier som hjälper mig att komma igång snabbt. Den uppenbara vägen för lärande är att läsa dokumentation och bli bekant med den nya tekniken. Men medan du kommer att lära dig mycket om struktur, kommer den vägen inte att hjälpa dig att lära dig hörnfallen, som vanligtvis kommer med erfarenhet. (“Hörnfall” är en teknisk term som hänvisar till en situation som uppstår utanför normala driftsparametrar.)

ett sätt att påskynda denna process för att få erfarenhet är att ta frågebaserade resurser som Stack Overflow och Quora och bara läsa igenom dem som en bok. Hitta de mest populära frågorna om biblioteket du lär dig och se vilken typ av problem andra människor vanligtvis stöter på. Du kommer inte nödvändigtvis att stöta på dem själv, men bara att veta vad som är möjligt är som att skina ett starkt ljus på din Tankekarta över de nya ideerna.

utnyttja Stack Overflow frågor för att få erfarenhet snabbt. Kredit: Stack Overflow

för ett mer målinriktat tillvägagångssätt, hitta information om biblioteksfunktioner som används i ditt nya projekt specifikt. Titta på de som är nya för dig och lära dem i förväg, innan du måste röra den koden alls.

dela dina förslag