Sedan början av 2018 innehar jag positionen som lead/boss/lead developer i teamet – kalla det vad du vill, men poängen är att jag är helt ansvarig för en av modulerna och för alla utvecklare som jobbar på det. Denna tjänst ger mig ett nytt perspektiv på utvecklingsprocessen, då jag är involverad i fler projekt och mer aktivt involverad i beslutsfattande. Nyligen, tack vare dessa två saker, insåg jag plötsligt hur mycket måttet på förståelse påverkar koden och applikationen.
Poängen jag vill framhålla är att kvaliteten på koden (och slutprodukten) är nära relaterad till hur medvetna personerna som designar och skriver koden är om vad de gör.
Du kanske tänker just nu, "Tack, Cap. Visst vore det trevligt att förstå vad du skriver i allmänhet. Annars kan du lika gärna anlita en grupp apor för att slå godtyckliga nycklar och låta det vara kvar." Och du har helt rätt. Följaktligen tar jag det för givet att du inser att det är nödvändigt att ha en allmän uppfattning om vad du gör. Detta kan kallas nollnivån av förståelse, och vi kommer inte att analysera det i detalj. Vi kommer att titta i detalj på vad just du behöver förstå och hur det påverkar de beslut du fattar varje dag. Om jag hade vetat dessa saker i förväg, skulle det ha besparat mig mycket slöseri med tid och tveksam kod.
Även om du inte kommer att se en enda rad kod nedan, tror jag fortfarande att allt som sägs här är av stor betydelse för att skriva högkvalitativ, uttrycksfull kod.
Första nivån av förståelse: Varför fungerar det inte?
Utvecklare når vanligtvis denna nivå mycket tidigt i sina karriärer, ibland även utan hjälp från andra – åtminstone enligt min erfarenhet. Föreställ dig att du har fått en felrapport: någon funktion i applikationen fungerar inte, den måste åtgärdas. Hur kommer du att gå vidare?
Standardschemat ser ut så här:
- Hitta kodbiten som orsakar problemet (hur man gör detta är ett separat ämne, jag tar upp det i min bok om äldre kod)
- Gör ändringar i det här utdraget
- Se till att felet är åtgärdat och att inga regressionsfel har inträffat
Låt oss nu fokusera på den andra punkten - att göra ändringar i koden. Det finns två tillvägagångssätt för denna process. Det första är att fördjupa sig i exakt vad som händer i den aktuella koden, identifiera felet och åtgärda det. För det andra: flytta efter känsla - lägg till, säg, +1 till ett villkorligt uttalande eller loop, se om funktionen fungerar i det önskade scenariot, försök sedan något annat, och så vidare i oändlighet.
Det första tillvägagångssättet är korrekt. Som Steve McConnell förklarar i sin bok Code Complete (som jag för övrigt rekommenderar starkt), varje gång vi ändrar något i koden bör vi med tillförsikt kunna förutsäga hur det kommer att påverka applikationen. Jag citerar från minnet, men om en buggfix inte fungerar som du förväntade dig bör du vara mycket orolig och du bör ifrågasätta hela din handlingsplan.
För att sammanfatta vad som har sagts, för att utföra en bra buggfix som inte försämrar kodens kvalitet, måste du förstå både hela strukturen i koden och källan till det specifika problemet.
Andra nivån av förståelse: Varför fungerar det?
Denna nivå förstås mycket mindre intuitivt än den föregående. Jag, medan jag fortfarande var nybörjare, lärde mig det tack vare min chef och förklarade sedan upprepade gånger kärnan i saken för nykomlingar.
Den här gången, låt oss föreställa oss att du fick två felrapporter samtidigt: den första handlar om scenario A, den andra handlar om scenario B. I båda scenarierna händer något fel. Följaktligen tacklar du den första buggen först. Med hjälp av principerna som vi utvecklat för att förstå nivå XNUMX, gräver du djupt i koden som är relevant för problemet, tar reda på varför den får applikationen att uppföra sig som den gör i scenario A och gör rimliga justeringar som ger det resultat du vill ha. förväntat. . Allt går jättebra.
Sedan går du vidare till scenario B. Du upprepar scenariot i ett försök att provocera fram ett misstag, men — överraskning! – nu fungerar allt som det ska. För att bekräfta din gissning ångrar du ändringarna du gjorde medan du arbetade med bugg A, och bugg B kommer tillbaka. Din buggfix löste båda problemen. Tur!
Du räknade inte med det här alls. Du har kommit på ett sätt att åtgärda felet i scenario A och har ingen aning om varför det fungerade för scenario B. I det här skedet är det mycket frestande att tro att båda uppgifterna har slutförts framgångsrikt. Detta är ganska logiskt: poängen var att eliminera fel, eller hur? Men arbetet är inte avslutat än: du måste fortfarande ta reda på varför dina handlingar korrigerade felet i scenario B. Varför? För det kanske fungerar på fel principer, och då måste du leta efter en annan utväg. Här är ett par exempel på sådana fall:
- Eftersom lösningen inte var anpassad till fel B, med hänsyn till alla faktorer, kan du omedvetet ha brutit funktion C.
- Det är möjligt att det också finns en tredje bugg som lurar någonstans, relaterad till samma funktion, och din buggfix beror på den för att systemet ska fungera korrekt i scenario B. Allt ser bra ut nu, men en dag kommer denna tredje bugg att märkas och fixas. Sedan i scenario B kommer felet att uppstå igen, och det är bra om det bara finns där.
Allt detta lägger till kaos i koden och kommer en dag att falla på ditt huvud - troligen i det mest olämpliga ögonblicket. Du måste samla din viljestyrka för att tvinga dig själv att lägga tid på att förstå varför allt verkar fungera, men det är värt det.
Tredje nivån av förståelse: Varför fungerar det?
Min senaste insikt relaterar just till denna nivå, och det är förmodligen den som skulle ha gett mig mest nytta om jag hade kommit till denna idé tidigare.
För att göra det tydligare, låt oss titta på ett exempel: din modul måste göras kompatibel med funktion X. Du är inte särskilt bekant med funktion X, men du fick höra att du måste använda F-ramverket för att vara kompatibel med den. moduler som integreras med X fungerar exakt med honom.
Din kod har inte varit i kontakt med F-ramverket alls sedan den första dagen av dess liv, så att implementera den kommer inte att vara så lätt. Detta kommer att få allvarliga konsekvenser för vissa delar av modulen. Men du kastar dig in i utvecklingen: du spenderar veckor på att skriva kod, testa, rulla ut pilotversioner, få feedback, åtgärda regressionsfel, upptäcka oförutsedda komplikationer, inte hålla de ursprungligen överenskomna deadlines, skriva lite mer kod, testa, få feedbackkommunikation, korrigera regressionsfel - allt detta för att implementera F-ramverket.
Och någon gång inser du plötsligt - eller kanske hör av någon - att ramverk F kanske inte alls ger dig kompatibilitet med funktion X. Kanske har all den tid och ansträngning lagts helt fel på det.
Något liknande hände en gång när jag arbetade med ett projekt som jag var ansvarig för. Varför hände det här? Eftersom jag hade liten förståelse för vad funktion X var och hur det förhöll sig till ram F. Vad skulle jag ha gjort? Be personen som tilldelar utvecklingsuppgiften att tydligt förklara hur det avsedda handlingssättet leder till det önskade resultatet, snarare än att bara upprepa vad som gjordes för andra moduler eller ta på ord för det att detta är vad funktion X behöver göra.
Erfarenheterna av detta projekt lärde mig att vägra att påbörja utvecklingsprocessen förrän vi har en klar förståelse för varför vi uppmanas att göra vissa saker. Vägra direkt. När du får en uppgift är den första impulsen att genast ta dig an den för att inte slösa tid. Men policyn "frysa projektet tills vi kommer in i alla detaljer" kan minska tidsspillan i storleksordningar.
Även om de försöker sätta press på dig, för att tvinga dig att börja arbeta, fastän du inte förstår skälen till detta, gör motstånd. Ta först reda på varför du får en sådan uppgift och avgör om detta är rätt väg till målet. Jag var tvungen att lära mig allt detta den hårda vägen - jag hoppas att mitt exempel kommer att göra livet lättare för dem som läser detta.
Fjärde nivån av förståelse: ???
Det finns alltid mer att lära i programmering, och jag tror att jag bara har skrapat på ytan av ämnet förståelse. Vilka andra nivåer av förståelse har du upptäckt under åren av att arbeta med kod? Vilka beslut tog du som hade en positiv inverkan på kvaliteten på koden och tillämpningen? Vilka beslut visade sig vara felaktiga och lärde dig en värdefull läxa? Dela din upplevelse i kommentarerna.
Källa: will.com