Siden begynnelsen av 2018 har jeg hatt stillingen som lead/sjef/leadutvikler på teamet – kall det hva du vil, men poenget er at jeg er helt ansvarlig for en av modulene og for alle utviklerne som jobber på den. Denne stillingen gir meg et nytt perspektiv på utviklingsprosessen, da jeg er involvert i flere prosjekter og mer aktivt involvert i beslutningstaking. Nylig, takket være disse to omstendighetene, innså jeg plutselig hvor mye forståelsen påvirker koden og applikasjonen.
Poenget jeg vil fremheve er at kvaliteten på koden (og sluttproduktet) er nært knyttet til hvor bevisste personene som designer og skriver koden er på hva de gjør.
Du tenker kanskje akkurat nå, "Takk, Cap. Selvfølgelig ville det vært fint å forstå hva du skriver generelt. Ellers kan du like gjerne leie en gruppe aper til å trykke på vilkårlige nøkler og la det være med det.» Og du har helt rett. Derfor tar jeg det for gitt at du innser at det er nødvendig å ha en generell ide om hva du gjør. Dette kan kalles nullnivået av forståelse, og vi vil ikke analysere det i detalj. Vi vil se i detalj på hva akkurat du trenger å forstå og hvordan det påvirker beslutningene du tar hver dag. Hvis jeg hadde visst disse tingene på forhånd, ville det ha spart meg for mye bortkastet tid og tvilsom kode.
Selv om du ikke vil se en eneste linje med kode nedenfor, tror jeg fortsatt at alt som er sagt her er av stor betydning for å skrive høykvalitets, uttrykksfull kode.
Første nivå av forståelse: Hvorfor fungerer det ikke?
Utviklere når vanligvis dette nivået veldig tidlig i karrieren, noen ganger til og med uten hjelp fra andre – i hvert fall etter min erfaring. Tenk deg at du har mottatt en feilrapport: noen funksjoner i applikasjonen fungerer ikke, den må fikses. Hvordan vil du gå frem?
Standardopplegget ser slik ut:
- Finn kodebiten som forårsaker problemet (hvordan du gjør dette er et eget emne, jeg dekker det i boken min om eldre kode)
- Gjør endringer i denne kodebiten
- Sørg for at feilen er rettet og at ingen regresjonsfeil har oppstått
La oss nå fokusere på det andre punktet - å gjøre endringer i koden. Det er to tilnærminger til denne prosessen. Den første er å fordype seg i hva som skjer i gjeldende kode, identifisere feilen og fikse den. For det andre: flytt etter følelse - legg til for eksempel +1 til en betinget setning eller løkke, se om funksjonen fungerer i ønsket scenario, prøv så noe annet, og så videre i det uendelige.
Den første tilnærmingen er riktig. Som Steve McConnell forklarer i sin bok Code Complete (som jeg anbefaler på det sterkeste), hver gang vi endrer noe i koden, bør vi være i stand til å forutsi med sikkerhet hvordan det vil påvirke applikasjonen. Jeg siterer fra minnet, men hvis en feilretting ikke fungerer slik du forventet, bør du være veldig skremt, og du bør stille spørsmål ved hele handlingsplanen din.
For å oppsummere det som er sagt, for å utføre en god feilretting som ikke forringer kvaliteten på koden, må du forstå både hele strukturen til koden og kilden til det spesifikke problemet.
Andre nivå av forståelse: Hvorfor fungerer det?
Dette nivået forstås mye mindre intuitivt enn det forrige. Mens jeg fortsatt var en nybegynner utvikler, lærte jeg det takket være sjefen min, og forklarte deretter gjentatte ganger essensen av saken for nykommere.
Denne gangen, la oss forestille oss at du mottok to feilrapporter samtidig: den første handler om scenario A, den andre handler om scenario B. I begge scenariene skjer det noe galt. Følgelig takler du den første feilen først. Ved å bruke prinsippene vi utviklet for nivå XNUMX-forståelse, graver du dypt inn i koden som er relevant for problemet, finner ut hvorfor den får applikasjonen til å oppføre seg slik den gjør i scenario A, og gjør rimelige justeringer som gir det resultatet du ønsker. . Alt går kjempebra.
Deretter går du videre til scenario B. Du gjentar scenariet i et forsøk på å provosere frem en feil, men — overraskelse! – Nå fungerer alt som det skal. For å bekrefte gjetningen din angrer du endringene du gjorde mens du jobbet med feil A, og feil B kommer tilbake. Feilrettingen din løste begge problemene. Heldig!
Du har ikke regnet med dette i det hele tatt. Du har kommet opp med en måte å fikse feilen i scenario A og aner ikke hvorfor det fungerte for scenario B. På dette stadiet er det veldig fristende å tro at begge oppgavene er fullført. Dette er ganske logisk: poenget var å eliminere feil, var det ikke? Men arbeidet er ikke ferdig ennå: du må fortsatt finne ut hvorfor handlingene dine korrigerte feilen i scenario B. Hvorfor? Fordi det kanskje fungerer etter feil prinsipper, og da må du lete etter en annen utvei. Her er et par eksempler på slike tilfeller:
- Siden løsningen ikke var skreddersydd til feil B, tar alle faktorer i betraktning, kan det hende at du uvitende har ødelagt funksjon C.
- Det er mulig at det også er en tredje feil som lurer et sted, relatert til den samme funksjonen, og feilrettingen din avhenger av den for riktig drift av systemet i scenario B. Alt ser bra ut nå, men en dag vil denne tredje feilen bli lagt merke til og fikset. Så i scenario B vil feilen oppstå igjen, og det er bra om det bare er der.
Alt dette legger kaos til koden og vil en dag falle på hodet ditt - mest sannsynlig i det mest uleilige øyeblikket. Du må mønstre viljestyrken din for å tvinge deg selv til å bruke tid på å forstå hvorfor alt ser ut til å fungere, men det er verdt det.
Tredje nivå av forståelse: Hvorfor fungerer det?
Min nylige innsikt relaterer seg nettopp til dette nivået, og det er sannsynligvis den som ville gitt meg mest nytte om jeg hadde kommet til denne ideen tidligere.
For å gjøre det klarere, la oss se på et eksempel: modulen din må gjøres kompatibel med funksjon X. Du er ikke spesielt kjent med funksjon X, men du ble fortalt at for å være kompatibel med den må du bruke F-rammeverket. Annet moduler som integreres med X fungerer nøyaktig med ham.
Koden din har ikke hatt noen kontakt med F-rammeverket siden den første dagen av livet, så det vil ikke være så lett å implementere det. Dette vil få alvorlige konsekvenser for enkelte deler av modulen. Men du kaster deg ut i utviklingen: du bruker uker på å skrive kode, teste, rulle ut pilotversjoner, få tilbakemelding, fikse regresjonsfeil, oppdage uforutsette komplikasjoner, ikke overholde de opprinnelig avtalte tidsfristene, skrive litt mer kode, teste, få tilbakemeldingskommunikasjon, korrigere regresjonsfeil - alt dette for å implementere F-rammeverket.
Og på et tidspunkt innser du plutselig - eller kanskje hører fra noen - at kanskje rammeverk F ikke vil gi deg kompatibilitet med funksjon X i det hele tatt. Kanskje all den tiden og kreftene ble lagt ned helt feil på det.
Noe lignende skjedde en gang mens jeg jobbet med et prosjekt jeg var ansvarlig for. Hvorfor skjedde dette? Fordi jeg hadde liten forståelse av hvilken funksjon X var og hvordan den forholdt seg til rammeverket F. Hva burde jeg ha gjort? Be personen som tildeler utviklingsoppgaven tydelig forklare hvordan den tiltenkte handlingen fører til det ønskede resultatet, i stedet for bare å gjenta det som ble gjort for andre moduler eller ta på ord for det at dette er hva funksjon X trenger å gjøre.
Erfaringen med dette prosjektet lærte meg å nekte å starte utviklingsprosessen før vi har en klar forståelse av hvorfor vi blir bedt om å gjøre visse ting. Nekter direkte. Når du mottar en oppgave, er den første impulsen å ta den umiddelbart for ikke å kaste bort tid. Men "frys prosjektet til vi kommer inn i alle detaljene"-politikken kan redusere bortkastet tid i størrelsesordener.
Selv om de prøver å legge press på deg, for å tvinge deg til å begynne å jobbe, selv om du ikke forstår begrunnelsen for dette, motstå. Finn først ut hvorfor du får en slik oppgave, og avgjør om dette er riktig vei til målet. Jeg måtte lære alt dette på den harde måten – jeg håper eksemplet mitt vil gjøre livet lettere for de som leser dette.
Fjerde nivå av forståelse: ???
Det er alltid mer å lære i programmering, og jeg tror jeg bare har skrapet i overflaten av emnet forståelse. Hvilke andre nivåer av forståelse har du oppdaget i løpet av årene du har jobbet med kode? Hvilke avgjørelser tok du som hadde en positiv innvirkning på kvaliteten på koden og applikasjonen? Hvilke avgjørelser viste seg å være feil og lærte deg en verdifull lekse? Del opplevelsen din i kommentarene.
Kilde: www.habr.com