Siden starten af 2018 har jeg haft stillingen som lead/boss/lead developer på teamet – kald det hvad du vil, men pointen er, at jeg er helt ansvarlig for et af modulerne og for alle de udviklere, der arbejder. på det. Denne stilling giver mig et nyt perspektiv på udviklingsprocessen, da jeg er involveret i flere projekter og mere aktivt involveret i beslutningstagning. For nylig, takket være disse to ting, indså jeg pludselig, hvor meget forståelsen påvirker koden og applikationen.
Pointen, jeg vil fremhæve, er, at kvaliteten af koden (og det endelige produkt) er tæt forbundet med, hvor bevidste de mennesker, der designer og skriver koden, er på, hvad de laver.
Du tænker måske lige nu: "Tak, Cap. Det ville selvfølgelig være rart at forstå, hvad du skriver generelt. Ellers kan du lige så godt hyre en gruppe aber til at trykke på vilkårlige nøgler og lade det være." Og du har fuldstændig ret. Derfor tager jeg det for givet, at du indser, at det er nødvendigt at have en generel idé om, hvad du laver. Dette kan kaldes nulniveauet af forståelse, og vi vil ikke analysere det i detaljer. Vi vil se nærmere på, hvad præcis du skal forstå, 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 en masse spildtid og tvivlsom kode.
Selvom du ikke vil se en eneste linje kode nedenfor, tror jeg stadig, at alt, der er sagt her, er af stor betydning for at skrive højkvalitets, udtryksfuld kode.
Første niveau af forståelse: Hvorfor virker det ikke?
Udviklere når normalt dette niveau meget tidligt i deres karriere, nogle gange endda uden hjælp fra andre - i hvert fald efter min erfaring. Forestil dig, at du har modtaget en fejlrapport: en eller anden funktion i applikationen virker ikke, den skal rettes. Hvordan vil du fortsætte?
Standardskemaet ser således ud:
- Find det stykke kode, der forårsager problemet (hvordan man gør dette er et separat emne, jeg dækker det i min bog om ældre kode)
- Foretag ændringer af dette uddrag
- Sørg for, at fejlen er rettet, og at der ikke er opstået regressionsfejl
Lad os nu fokusere på det andet punkt - at lave ændringer i koden. Der er to tilgange til denne proces. Den første er at dykke ned i, hvad der præcist sker i den aktuelle kode, identificere fejlen og rette den. For det andet: bevæg dig efter følelse - føj f.eks. +1 til en betinget erklæring eller loop, se om funktionen virker i det ønskede scenarie, prøv så noget andet, og så videre i det uendelige.
Den første tilgang er korrekt. Som Steve McConnell forklarer i sin bog Code Complete (som jeg i øvrigt varmt anbefaler), hver gang vi ændrer noget i koden, bør vi være i stand til med sikkerhed at forudsige, hvordan det vil påvirke applikationen. Jeg citerer fra hukommelsen, men hvis en fejlrettelse ikke virker, som du forventede, bør du være meget foruroliget, og du bør stille spørgsmålstegn ved hele din handlingsplan.
For at opsummere, hvad der er blevet sagt, for at udføre en god fejlrettelse, der ikke forringer kodens kvalitet, skal du forstå både hele strukturen af koden og kilden til det specifikke problem.
Andet niveau af forståelse: Hvorfor virker det?
Dette niveau forstås meget mindre intuitivt end det foregående. Jeg, mens jeg stadig var nybegynder udvikler, lærte det takket være min chef og forklarede efterfølgende gentagne gange essensen af sagen for nytilkomne.
Lad os denne gang forestille os, at du modtog to fejlrapporter på én gang: den første handler om scenario A, den anden handler om scenario B. I begge scenarier sker der noget galt. Derfor tackler du den første fejl først. Ved at bruge de principper, vi udviklede til niveau XNUMX-forståelse, graver du dybt ned i den kode, der er relevant for problemet, finder ud af, hvorfor den får applikationen til at opføre sig, som den gør i Scenario A, og foretager rimelige justeringer, der giver det resultat, du ønsker. . Alt går fantastisk.
Så går du videre til scenario B. Du gentager scenariet i et forsøg på at fremprovokere en fejl, men – overraskelse! - nu virker alt, som det skal. For at bekræfte dit gæt, fortryder du de ændringer, du lavede, mens du arbejdede med fejl A, og fejl B kommer tilbage. Din fejlrettelse løste begge problemer. Heldig!
Det regnede du slet ikke med. Du har fundet på en måde at rette fejlen i scenarie A og har ingen idé om, hvorfor det virkede for scenarie B. På dette stadium er det meget fristende at tro, at begge opgaver er blevet gennemført med succes. Dette er ret logisk: Pointen var at eliminere fejl, var det ikke? Men arbejdet er ikke færdigt endnu: du skal stadig finde ud af, hvorfor dine handlinger korrigerede fejlen i scenario B. Hvorfor? For det kan være, at det fungerer efter de forkerte principper, og så bliver du nødt til at lede efter en anden vej ud. Her er et par eksempler på sådanne tilfælde:
- Da løsningen ikke var skræddersyet til fejl B, under hensyntagen til alle faktorer, kan du ubevidst have brudt funktion C.
- Det er muligt, at der også lurer en tredje fejl et sted, relateret til den samme funktion, og din fejlrettelse afhænger af den for den korrekte drift af systemet i scenario B. Alt ser godt ud nu, men en dag vil denne tredje fejl blive bemærket og rettet. Så i scenarie B vil fejlen opstå igen, og det er godt, hvis bare der.
Alt dette tilføjer kaos til koden og vil en dag falde dig over hovedet - højst sandsynligt i det mest uhensigtsmæssige øjeblik. Du bliver nødt til at mønstre din viljestyrke for at tvinge dig selv til at bruge tid på at forstå, hvorfor alt ser ud til at fungere, men det er det værd.
Tredje niveau af forståelse: Hvorfor virker det?
Min seneste indsigt relaterer sig netop til dette niveau, og det er nok det, der ville have givet mig mest udbytte, hvis jeg var kommet til denne idé tidligere.
For at gøre det klarere, lad os se på et eksempel: dit modul skal gøres kompatibelt med funktion X. Du er ikke særlig bekendt med funktion X, men du fik at vide, at du skal bruge F-rammeværket for at være kompatibelt med det. moduler, der integreres med X, fungerer præcist med ham.
Din kode har slet ikke været i kontakt med F-frameworket siden den første dag af dens levetid, så det bliver ikke så let at implementere det. Dette vil have alvorlige konsekvenser for nogle dele af modulet. Du kaster dig dog ud i udvikling: du bruger uger på at skrive kode, teste, udrulle pilotversioner, få feedback, rette regressionsfejl, opdage uforudsete komplikationer, ikke overholde de oprindeligt aftalte deadlines, skrive noget mere kode, teste, få feedbackkommunikation, korrigering af regressionsfejl - alt dette for at implementere F-rammen.
Og på et tidspunkt indser du pludselig - eller hører måske fra nogen - at ramme F måske slet ikke vil give dig kompatibilitet med feature X. Måske er al den tid og kræfter brugt helt forkert på det.
Noget lignende skete en gang, mens jeg arbejdede på et projekt, som jeg var ansvarlig for. Hvorfor skete dette? Fordi jeg havde ringe forståelse for, hvad funktion X var, og hvordan den forholdt sig til ramme F. Hvad skulle jeg have gjort? Bed den person, der tildeler udviklingsopgaven, om klart at forklare, hvordan den tilsigtede handling fører til det ønskede resultat, i stedet for blot at gentage, hvad der blev gjort for andre moduler eller tage deres ord for det, at det er det, funktion X skal gøre.
Erfaringen med dette projekt lærte mig at nægte at begynde udviklingsprocessen, før vi har en klar forståelse af, hvorfor vi bliver bedt om at gøre visse ting. Afslå direkte. Når du modtager en opgave, er den første impuls, at du straks tager fat på den for ikke at spilde tiden. Men politikken om at "fryse projektet, indtil vi kommer ind i alle detaljerne" kan reducere spildtid i størrelsesordener.
Selv hvis de prøver at lægge pres på dig, for at tvinge dig til at begynde at arbejde, selvom du ikke forstår begrundelsen for dette, så modstå. Find først ud af, hvorfor du får sådan en opgave, og afgør, om det er den rigtige vej til målet. Jeg var nødt til at lære alt dette på den hårde måde - jeg håber, at mit eksempel vil gøre livet lettere for dem, der læser dette.
Fjerde niveau af forståelse: ???
Der er altid mere at lære i programmering, og jeg tror, at jeg kun har ridset overfladen af emnet forståelse. Hvilke andre niveauer af forståelse har du opdaget gennem årene, hvor du har arbejdet med kode? Hvilke beslutninger tog du, som havde en positiv indvirkning på kvaliteten af koden og applikationen? Hvilke beslutninger viste sig at være forkerte og lærte dig en værdifuld lektie? Del din oplevelse i kommentarerne.
Kilde: www.habr.com