Sedan början av 2018 har jag haft rollen som ledare/chef/huvudutvecklare i teamet â kalla det vad du vill, men i grund och botten Ă€r jag helt ansvarig för en av modulerna och för alla utvecklare som arbetar med den. Denna position ger mig ett nytt perspektiv pĂ„ utvecklingsprocessen, dĂ„ jag Ă€r involverad i fler projekt och deltar mer aktivt i beslutsfattandet. Nyligen, tack vare dessa tvĂ„ omstĂ€ndigheter, insĂ„g jag ovĂ€ntat hur mycket graden av förstĂ„else pĂ„verkar koden och applikationen.
Tanken jag vill uttrycka Àr att kvaliteten pÄ koden (och den slutliga produkten) Àr nÀra knuten till hur mycket de personer som designar och skriver koden Àr medvetna om vad de faktiskt gör.
Du kanske nu tÀnker: "Tack, kapten. SjÀlvklart Àr det viktigt att förstÄ vad man skriver. Annars kan det lika gÀrna anstÀlla en grupp apor som slÄr pÄ tangenterna helt utan mÄl, och dÀrmed vara nöjda." Och du har helt rÀtt. DÀrför tar jag det för givet: du Àr medveten om att ha en övergripande förstÄelse för vad du gör Àr nödvÀndigt. Detta kan kallas nollnivÄ av förstÄelse och den kommer vi inte att gÄ in pÄ ingÄende. Vi kommer istÀllet att fokusera pÄ vad som specifikt behöver förstÄs och hur detta pÄverkar de beslut du fattar varje dag. Om jag hade kÀnt till dessa saker i förvÀg skulle jag ha undvikit en mÀngd bortkastad tid och tveksamt kod.
Ăven om du inte kommer att se ett enda kodstycke nedan, anser jag Ă€ndĂ„ att allt som sĂ€gs hĂ€r har stor betydelse för att skriva kvalitativ, uttrycksfull kod.
Första nivÄ av förstÄelse: Varför fungerar det inte?
Utvecklare nĂ„r vanligtvis denna nivĂ„ i de tidigaste skedena av sin karriĂ€r, ibland till och med utan nĂ„got stöd frĂ„n omgivningen â Ă„tminstone enligt mina observationer. FörestĂ€ll dig att du har fĂ„tt en buggrapport: en viss funktion i applikationen fungerar inte, och den mĂ„ste Ă„tgĂ€rdas. Hur agerar du?
Standardmönstret ser ut sÄ hÀr:
- Hitta den kodsnutt som orsakar problemet (hur man gör detta Àr ett separat Àmne, vilket jag behandlar i min bok om förÄldrad kod)
- Gör Àndringar i denna kodsnutt
- Förvissa dig om att buggen Àr ÄtgÀrdad och inga regressionsfel har uppstÄtt
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. För det första: att förstÄ vad som faktiskt hÀnder i den nuvarande koden, identifiera felet och fixa det. För det andra: att gÄ fram pÄ mÄfÄ - lÀgga till, sÀg, +1 i en villkorssats eller loop, se om funktionen fungerar i det aktuella scenariot, försöka med nÄgot annat och sÄ vidare i oÀndlighet.
Det korrekta tillvÀgagÄngssÀttet Àr det första. Som Steve McConnell förklarar i sin bok Code Complete (förresten, jag rekommenderar den verkligen), varje gÄng vi gör Àndringar i koden mÄste vi kunna förutsÀga hur det kommer att pÄverka applikationen. Jag citerar ur minnet, men om en buggfix inte fungerar som du förvÀntade dig, ska det vÀcka allvarlig oro, och du mÄste ifrÄgasÀtta hela din handlingsplan.
Sammanfattningsvis, för att göra en ordentlig buggfix utan att sÀnka kodens kvalitet, mÄste man förstÄ sÄvÀl hela kodstrukturen som kÀllan till det specifika problemet.
Den andra nivÄn av förstÄelse: Varför fungerar det?
Denna nivÄ Àr mycket mindre intuitiv Àn den föregÄende. NÀr jag fortfarande var en nybörjare som utvecklare insÄg jag detta tack vare min chef, och senare har jag mÄnga gÄnger förklarat saken för nykomlingar.
Denna gÄng lÄt oss förestÀlla oss att du fÄr tvÄ buggrapporter pÄ en gÄng: den första handlar om scenario A, den andra om scenario B. I bÄda scenarierna hÀnder nÄgot fel. DÀrför börjar du med det första felet. Med hjÀlp av de principer som vi har dragit för den första förstÄelsenivÄn fördjupar du dig vÀl i koden som rör problemet, tar reda pÄ varför det fÄr applikationen att bete sig pÄ det sÀttet i scenario A, och gör rimliga justeringar som ger precis det resultat du förvÀntade dig. Allt gÄr bra.
DÀrefter gÄr du vidare till scenario B. Du upprepar scenariot i ett försök att provocera fram felet, men - överraskning! - nu fungerar allt som det ska. För att bekrÀfta din gissning Ängrar du de Àndringar som gjordes under arbetet med fel A, och bugg B Äterkommer. Din buggfix löste bÄda problemen. Vilken tur!
Du hade inte alls rÀknat med detta. Du har kommit pÄ ett sÀtt att ÄtgÀrda felet i scenario A och har ingen aning om varför det fungerade Àven för scenario B. Vid det hÀr laget Àr det frestande att dra slutsatsen att bÄda uppgifterna har blivit framgÄngsrikt genomförda. Det kÀnns logiskt: syftet var ju att ÄtgÀrda felen, eller hur? Men arbetet Àr inte avslutat: du mÄste fortfarande lista ut varför dina ÄtgÀrder löste felet i scenario B. Varför? För att det kanske fungerar pÄ felaktiga principer, och dÄ mÄste du leta efter en annan lösning. HÀr Àr ett par exempel pÄ sÄdana fall:
- eftersom lösningen inte var specifikt riktad mot fel B med hÀnsyn till alla faktorer, kan det hÀnda att du, utan att inse det, har brutit funktionen C.
- Det Àr inte omöjligt att det finns en tredje bugg som gömmer sig nÄgonstans, kopplad till samma funktion, och din buggfix binder systemets korrekta funktion i scenario B till den. Just nu ser allt bra ut, men en dag kommer den tredje buggen att upptÀckas och ÄtgÀrdas. DÄ kommer det Äterigen att uppstÄ ett fel i scenario B, och helst inte bara dÀr.
Allt detta bidrar till en kaosartad kod och kommer en dag att falla tillbaka pĂ„ dig â troligtvis vid det mest olĂ€mpliga tillfĂ€llet. Du fĂ„r samla kraft för att tvinga dig sjĂ€lv att spendera tid pĂ„ att förstĂ„ varför allt ser ut att fungera, men det Ă€r vĂ€rt det.
Tredje nivÄn av förstÄelse: Varför fungerar det?
Min senaste insikt Àr just relaterad till denna nivÄ, och det Àr förmodligen den som skulle ge mig störst fördelar om jag hade kommit pÄ detta tidigare.
För att förtydliga, lÄt oss ta ett exempel: din modul behöver göras kompatibel med funktion X. Du Àr inte sÀrskilt vÀlbekant med funktion X, men du har fÄtt veta att för kompatibilitet mÄste du anvÀnda ramverket F. Andra moduler som integreras med X fungerar just med det.
Din kod har frĂ„n och med dag ett aldrig kommit i kontakt med ramverket F, sĂ„ att implementera det kommer inte att vara sĂ„ enkelt. Detta kan medföra allvarliga konsekvenser för vissa delar av modulen. ĂndĂ„ kastar du dig helhjĂ€rtat in i utvecklingen: du skriver kod i flera veckor, testar, lanserar pilotversioner, fĂ„r feedback, rĂ€ttar regressionsfel, upptĂ€cker oförutsedda komplikationer, hinner inte med de ursprungligen överenskomna tidsramarna, skriver mer kod, testar, fĂ„r Ă„terkoppling, rĂ€ttar regressionsfel â allt detta för att implementera ramverket F.
Och plötsligt inser du â eller kanske hör du frĂ„n nĂ„gon â att ramverket F kanske inte alls ger dig kompatibilitet med funktion X. Kanske har all denna tid och kraft lagts pĂ„ helt fel saker.
NÄgot liknande hÀnde en gÄng under ett projekt jag ansvarade för. Hur kunde det bli sÄ? För att jag hade en dÄlig förstÄelse för vad funktion X handlade om och hur den relaterade till ramverket F. Vad borde jag ha gjort? FrÄgat personen som sÀtter upp utvecklingsuppgiften om en tydlig förklaring av hur den föreslagna planen leder till det önskade resultatet, istÀllet för att bara upprepa vad som gjorts för andra moduler eller tro pÄ att det var nödvÀndigt för att funktion X skulle fungera.
Erfarenheten frÄn det hÀr projektet lÀrde mig att jag mÄste vÀgra att pÄbörja utvecklingsprocessen innan vi har en klar förstÄelse för varför vi ombeds att utföra vissa ÄtgÀrder. Att tydligt vÀgra. NÀr man fÄr en uppgift Àr den första impulsen att omedelbart ta tag i den för att inte slösa bort tid. Men policyn "stoppa projektet tills vi begriper allt" kan spara massa onödig tid.
Ăven om du pressas av andra att börja arbeta, Ă€ven om du inte förstĂ„r varför â stĂ„ emot. Först mĂ„ste du reda ut vad syftet med uppgiften Ă€r och om det Ă€r den rĂ€tta vĂ€gen till mĂ„let. Jag fick lĂ€ra mig allt detta pĂ„ hĂ„rda vĂ€gar â jag hoppas att mitt exempel kan göra livet enklare för dem som lĂ€ser detta.
FjÀrde nivÄn av förstÄelse: ???
Inom programmering finns det alltid nÄgot att lÀra sig, och jag tror att jag bara har berört ytan av Àmnet förstÄelse. Vilka andra nivÄer av förstÄelse har du upptÀckt under dina Är med kodning? Vilka beslut har du tagit som har förbÀttrat kvaliteten pÄ koden och applikationen? Vilka beslut har visat sig vara felaktiga och gett dig vÀrdefulla lÀrdomar? Dela med dig av dina erfarenheter i kommentarerna.
KĂ€lla: habr.com
