{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Accepter ikke at udvikle noget, du ikke forst\u00e5r","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Accepter
\n
\nSiden begyndelsen af 2018 har jeg haft rollen som leder\/chef\/lead developer i teamet \u2014 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\u00e5 udviklingsprocessen, da jeg er involveret i flere projekter og deltager mere aktivt i beslutningstagningen. Nyligt, takket v\u00e6re disse to omst\u00e6ndigheder, inds\u00e5 jeg pludselig, hvor meget graden af forst\u00e5else p\u00e5virker koden og applikationen.<\/p>\n

Den tanke, jeg \u00f8nsker at formidle, er, at kvaliteten af koden (og det endelige produkt) er n\u00e6rt relateret til, hvor bevidste folk, der designer og skriver koden, er om, hvad de faktisk laver.<\/p>\n

Du t\u00e6nker m\u00e5ske nu: \"Tak, kaptajn. Selvf\u00f8lgelig er det en fordel at forst\u00e5, hvad man overhovedet skriver. Ellers kunne man lige s\u00e5 godt hyre en gruppe aber til at trykke p\u00e5 tilf\u00e6ldige taster, og s\u00e5 ville det v\u00e6re det.\" Og du har helt ret. Jeg tager derfor som et givet, at du er klar over, at det er n\u00f8dvendigt at have en generel forst\u00e5else af, hvad du laver. Dette kan kaldes nul-niveau forst\u00e5else, og det vil vi ikke dykke ned i detaljer omkring. Vi vil derimod fokusere p\u00e5, hvad pr\u00e6cist der skal forst\u00e5s, og hvordan det p\u00e5virker de beslutninger, du tr\u00e6ffer hver dag. Hvis jeg havde vidst disse ting p\u00e5 forh\u00e5nd, ville det have sparet mig for meget spildt tid og tvivlsom kode.
\n<\/a><\/noindex>
\nSelvom 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\u00e6seren. <\/p>\n

F\u00f8rste niveau af forst\u00e5else: Hvorfor virker det ikke?<\/h4>\n

\nUdviklere n\u00e5r normalt til dette niveau i de tidligste faser af deres karriere, nogle gange endda uden assistance fra omgivelserne \u2014 i hvert fald if\u00f8lge 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?<\/p>\n

Det standardm\u00f8nster ser s\u00e5ledes ud:<\/p>\n

    \n
  1. Find den del af koden, der for\u00e5rsager problemet (hvordan det g\u00f8res, er et separat emne, som jeg beskriver i min bog om for\u00e6ldet kode)<\/li>\n
  2. Foretag \u00e6ndringer i denne del<\/li>\n
  3. S\u00f8rg for, at fejlen er l\u00f8st, og at der ikke er opst\u00e5et regressionsfejl.<\/li>\n<\/ol>\n

    \nLad os nu fokusere p\u00e5 det andet punkt \u2013 at foretage \u00e6ndringer i koden. Der er to tilgange til denne proces. Den f\u00f8rste: forst\u00e5, hvad der pr\u00e6cist sker i den nuv\u00e6rende kode, identificere fejlen og rette den. Den anden: g\u00e5 p\u00e5 gef\u00fchl \u2013 tilf\u00f8je, lad os sige, +1 i en betingelse eller en l\u00f8kke, se om denne funktion fungerer i det \u00f8nskede scenarie, s\u00e5 pr\u00f8ve noget andet og s\u00e5dan forts\u00e6tte i det uendelige.<\/p>\n

    Den f\u00f8rste tilgang er den korrekte. Som Steve McConnell forklarer i sin bog Code Complete (for \u00f8vrigt anbefaler jeg den varmt), skal vi hver gang vi \u00e6ndrer koden, v\u00e6re i stand til med sikkerhed at forudsige, hvordan det vil p\u00e5virke applikationen. Jeg citerer efter hukommelsen, men hvis en fejlfix ikke fungerer, som du forventede, b\u00f8r det v\u00e6kke din bekymring, og du skal stille sp\u00f8rgsm\u00e5lstegn ved hele din handlingsplan.<\/p>\n

    Sammenfattende skal man for at udf\u00f8re en ordentlig fejlfix, som ikke forringer kodekvaliteten, have forst\u00e5else for b\u00e5de hele kode-strukturen og kilden til det specifikke problem.<\/p>\n

    Andet niveau af forst\u00e5else: Hvorfor fungerer det?<\/h4>\n

    \nDette niveau er ikke lige s\u00e5 intuitivt at forst\u00e5 som det forrige. Da jeg stadig var en nybegynder udvikler, l\u00e6rte jeg det fra min chef, og jeg har senere mange gange selv forklaret essensen for nybegyndere.<\/p>\n

    Lad os denne gang forestille os, at du har modtaget to fejlrapporter samtidig: den f\u00f8rste handler om scenarie A, den anden om scenarie B. I begge scenarier sker der noget galt. Derfor g\u00e5r du f\u00f8rst i gang med den f\u00f8rste fejl. I henhold til de principper, vi har draget for det f\u00f8rste niveau af forst\u00e5else, dykker du grundigt ned i koden, der er relevant for problemet, finder ud af, hvorfor det f\u00e5r applikationen til at opf\u00f8re sig, som den g\u00f8r i scenarie A, og foretager rimelige justeringer, som giver det resultat, du forventede. Alt g\u00e5r godt.<\/p>\n

    Derefter g\u00e5r du videre til scenarie B. Du gentager scenariet i et fors\u00f8g p\u00e5 at fremprovokere fejlen, men \u2013 overraskelse! \u2013 nu virker alt som det skal. For at bekr\u00e6fte din formodning annullerer du de \u00e6ndringer, der blev foretaget under arbejdet med fejl A, og fejl B dukker op igen. Din fejlfix har l\u00f8st begge problemer. Heldigvis!<\/p>\n

    Du havde overhovedet ikke forudset dette. Du har opfundet en m\u00e5de at rette fejlen i scenario A, og du har ingen anelse om, hvorfor det ogs\u00e5 virkede for scenario B. P\u00e5 dette punkt er fristelsen stor til at konkludere, at begge opgaver er blevet l\u00f8st tilfredsstillende. Det virker logisk: form\u00e5let var at rette fejlene, var det ikke? Men arbejdet er ikke f\u00e6rdigt endnu: du skal stadig finde ud af, hvorfor dine handlinger rettede fejlen i scenario B. Hvorfor? Fordi det m\u00e5ske virker p\u00e5 forkerte principper, og s\u00e5 skal du lede efter en anden l\u00f8sning. Her er et par eksempler p\u00e5 s\u00e5danne tilf\u00e6lde:<\/p>\n