Siden begyndelsen af 2018 har jeg haft rollen som leder/chef/lead developer i teamet â kald det hvad du vil, men essensen er, at jeg har det fulde ansvar for en af modulerne og for alle udviklere, der arbejder med det. Denne stilling giver mig et nyt perspektiv pĂ„ udviklingsprocessen, da jeg er involveret i flere projekter og deltager mere aktivt i beslutningstagningen. Nyligt, takket vĂŠre disse to omstĂŠndigheder, indsĂ„ jeg pludselig, hvor meget graden af forstĂ„else pĂ„virker koden og applikationen.
Den tanke, jeg Ăžnsker at formidle, er, at kvaliteten af koden (og det endelige produkt) er nĂŠrt relateret til, hvor bevidste folk, der designer og skriver koden, er om, hvad de faktisk laver.
Du tÊnker mÄske nu: "Tak, kaptajn. SelvfÞlgelig er det en fordel at forstÄ, hvad man overhovedet skriver. Ellers kunne man lige sÄ godt hyre en gruppe aber til at trykke pÄ tilfÊldige taster, og sÄ ville det vÊre det." Og du har helt ret. Jeg tager derfor som et givet, at du er klar over, at det er nÞdvendigt at have en generel forstÄelse af, hvad du laver. Dette kan kaldes nul-niveau forstÄelse, og det vil vi ikke dykke ned i detaljer omkring. Vi vil derimod fokusere pÄ, hvad prÊcist der skal forstÄs, og hvordan det pÄvirker de beslutninger, du trÊffer hver dag. Hvis jeg havde vidst disse ting pÄ forhÄnd, ville det have sparet mig for meget spildt tid og tvivlsom kode.
Selvom du ikke vil se en eneste linje kode nedenfor, mener jeg stadig, at alt, hvad der siges her, er af stor betydning for at skrive kvalitetskode, der taler til lĂŠseren.
FÞrste niveau af forstÄelse: Hvorfor virker det ikke?
Udviklere nĂ„r normalt til dette niveau i de tidligste faser af deres karriere, nogle gange endda uden assistance fra omgivelserne â i hvert fald ifĂžlge mine observationer. Forestil dig, at du har modtaget en bug-rapport: En eller anden funktion i applikationen virker ikke, den skal rettes. Hvordan vil du handle?
Det standardmÞnster ser sÄledes ud:
- Find den del af koden, der forÄrsager problemet (hvordan det gÞres, er et separat emne, som jeg beskriver i min bog om forÊldet kode)
- Foretag ĂŠndringer i denne del
- SÞrg for, at fejlen er lÞst, og at der ikke er opstÄet regressionsfejl.
Lad os nu fokusere pĂ„ det andet punkt â at foretage ĂŠndringer i koden. Der er to tilgange til denne proces. Den fĂžrste: forstĂ„, hvad der prĂŠcist sker i den nuvĂŠrende kode, identificere fejlen og rette den. Den anden: gĂ„ pĂ„ gefĂŒhl â tilfĂžje, lad os sige, +1 i en betingelse eller en lĂžkke, se om denne funktion fungerer i det Ăžnskede scenarie, sĂ„ prĂžve noget andet og sĂ„dan fortsĂŠtte i det uendelige.
Den fÞrste tilgang er den korrekte. Som Steve McConnell forklarer i sin bog Code Complete (for Þvrigt anbefaler jeg den varmt), skal vi hver gang vi Êndrer koden, vÊre i stand til med sikkerhed at forudsige, hvordan det vil pÄvirke applikationen. Jeg citerer efter hukommelsen, men hvis en fejlfix ikke fungerer, som du forventede, bÞr det vÊkke din bekymring, og du skal stille spÞrgsmÄlstegn ved hele din handlingsplan.
Sammenfattende skal man for at udfÞre en ordentlig fejlfix, som ikke forringer kodekvaliteten, have forstÄelse for bÄde hele kode-strukturen og kilden til det specifikke problem.
Andet niveau af forstÄelse: Hvorfor fungerer det?
Dette niveau er ikke lige sÄ intuitivt at forstÄ som det forrige. Da jeg stadig var en nybegynder udvikler, lÊrte jeg det fra min chef, og jeg har senere mange gange selv forklaret essensen for nybegyndere.
Lad os denne gang forestille os, at du har modtaget to fejlrapporter samtidig: den fÞrste handler om scenarie A, den anden om scenarie B. I begge scenarier sker der noget galt. Derfor gÄr du fÞrst i gang med den fÞrste fejl. I henhold til de principper, vi har draget for det fÞrste niveau af forstÄelse, dykker du grundigt ned i koden, der er relevant for problemet, finder ud af, hvorfor det fÄr applikationen til at opfÞre sig, som den gÞr i scenarie A, og foretager rimelige justeringer, som giver det resultat, du forventede. Alt gÄr godt.
Derefter gĂ„r du videre til scenarie B. Du gentager scenariet i et forsĂžg pĂ„ at fremprovokere fejlen, men â overraskelse! â nu virker alt som det skal. For at bekrĂŠfte din formodning annullerer du de ĂŠndringer, der blev foretaget under arbejdet med fejl A, og fejl B dukker op igen. Din fejlfix har lĂžst begge problemer. Heldigvis!
Du havde overhovedet ikke forudset dette. Du har opfundet en mÄde at rette fejlen i scenario A, og du har ingen anelse om, hvorfor det ogsÄ virkede for scenario B. PÄ dette punkt er fristelsen stor til at konkludere, at begge opgaver er blevet lÞst tilfredsstillende. Det virker logisk: formÄlet var at rette fejlene, var det ikke? Men arbejdet er ikke fÊrdigt endnu: du skal stadig finde ud af, hvorfor dine handlinger rettede fejlen i scenario B. Hvorfor? Fordi det mÄske virker pÄ forkerte principper, og sÄ skal du lede efter en anden lÞsning. Her er et par eksempler pÄ sÄdanne tilfÊlde:
- da lĂžsningen ikke blev skrĂŠddersyet til fejl B under hensyntagen til alle faktorer, har du muligvis ubevidst brudt funktion C.
- det er ikke usandsynligt, at der ogsÄ gemmer sig en tredje fejl et sted, der relaterer sig til den samme funktion, og din bugfix binder det tilfredsstillende arbejde af systemet i scenario B til denne. Lige nu ser alt godt ud, men en dag vil den tredje fejl blive opdaget og rettet. SÄ vil der igen opstÄ en fejl i scenario B, og heldigvis kun der.
Alt dette tilfĂžjer kaos til koden og vil fĂžr eller senere ramme dig â sandsynligvis pĂ„ det mest ubelejlige tidspunkt. Du mĂ„ tage dig sammen for at tvinge dig selv til at bruge tid pĂ„ at forstĂ„, hvorfor alt tilsyneladende virker, men det er det vĂŠrd.
Tredje forstÄelsesniveau: Hvorfor virker det?
Min nylige indsigt er netop relateret til dette niveau, og det ville nok have givet mig de stĂžrste fordele, hvis jeg var kommet til den tanke tidligere.
For at gÞre det mere klart, lad os tage et eksempel: dit modul skal gÞres kompatibelt med funktion X. Du er ikke sÊrlig fortrolig med funktion X, men du har fÄet at vide, at for at vÊre kompatibel med det skal du bruge rammevÊrk F. Andre moduler, der integreres med X, arbejder netop med det.
Din kode har fra dag Ă©t ikke haft nogen forbindelse til rammevĂŠrket F, sĂ„ det vil ikke vĂŠre sĂ„ nemt at implementere det. Det vil fĂ„ alvorlige konsekvenser for nogle komponenter af modulet. Alligevel fordyber du dig i udviklingen: i flere uger skriver du kode, tester, lancerer pilotversioner, modtager feedback, retter regressionsfejl, opdager uventede komplikationer, overholder ikke de oprindeligt aftalte frister, skriver mere kode, tester, fĂ„r feedback, retter regressionsfejl â alt dette for at implementere rammevĂŠrket F.
Og pĂ„ et tidspunkt indser du pludselig â eller mĂ„ske hĂžrer du det fra nogen â at rammevĂŠrket F mĂ„ske slet ikke giver dig kompatibilitet med funktion X. MĂ„ske har al denne tid og kraft vĂŠret anvendt fuldstĂŠndig forkert.
Noget lignende skete en gang i forbindelse med et projekt, jeg var ansvarlig for. Hvordan skete det? Fordi jeg ikke forstod essensen af funktion X og hvordan den relaterer sig til rammevÊrket F. Hvad skulle jeg have gjort? Bedt en person, der opstiller opgaven til udviklingen, om klart at forklare, hvordan den planlagte handlingsplan fÞrer til det Þnskede resultat, i stedet for blot at gentage, hvad der blev gjort for andre moduler, eller tro pÄ ordet, at det var nÞdvendigt for at fÄ funktion X til at fungere.
Erfaringen fra dette projekt lĂŠrte mig at nĂŠgte at pĂ„begynde udviklingsprocessen, indtil vi har en klar forstĂ„else for, hvorfor vi bliver bedt om at udfĂžre visse handlinger. At afvise direkte. NĂ„r man fĂ„r en opgave, er den fĂžrste impuls â straks at tage fat pĂ„ den, for ikke at spilde tid. Men politikken "fryser projektet, indtil vi har alle detaljerne" kan reducere det spildte tid med hele rĂŠkkefĂžlge.
Selv hvis der prĂžves at presse dig, til at begynde arbejdet, selvom du ikke forstĂ„r begrundelsen â modstĂ„. FĂžrst skal du finde ud af, hvad mĂ„let med opgaven er, og beslutte, om det er den rigtige vej til at nĂ„ mĂ„let. Jeg mĂ„tte lĂŠre alt dette gennem bitter erfaring â jeg hĂ„ber, at mit eksempel vil gĂžre livet lettere for dem, der lĂŠser dette.
Fjerde niveau af forstÄelse: ???
I programmering er der altid noget at lÊre, og jeg mener, jeg kun har berÞrt de Þverste lag af emnet forstÄelse. Hvilke andre niveauer af forstÄelse har du opdaget i Ärenes lÞb med kode? Hvilke beslutninger har haft en positiv indvirkning pÄ kvaliteten af koden og applikationen? Hvilke beslutninger viste sig at vÊre fejlagtige og gav dig en vÊrdifuld lektion? Del dine erfaringer i kommentarerne.
Kilde: habr.com
