{"id":3016,"date":"2020-06-24T08:53:38","date_gmt":"2020-06-24T08:53:38","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/a-quick-primer-on-refactoring-for-beginners\/"},"modified":"2026-04-24T11:30:09","modified_gmt":"2026-04-24T11:30:09","slug":"en-hurtig-indforing-i-refaktorering-for-begyndere","status":"publish","type":"post","link":"https:\/\/thecodest.co\/da\/blog\/a-quick-primer-on-refactoring-for-beginners\/","title":{"rendered":"En hurtig introduktion til refaktorering for begyndere"},"content":{"rendered":"

Derfor er det uforst\u00e5eligt for nogle, at refaktorering<\/strong> er faktisk et omr\u00e5de inden for programmering, og det er ogs\u00e5 en meget vigtig del af programm\u00f8rens arbejde. Koden er i konstant udvikling, den vil blive \u00e6ndret, s\u00e5 l\u00e6nge der er mulighed for at tilf\u00f8je nye funktioner. Men den kan antage en form, der ikke l\u00e6ngere giver mulighed for effektivt at tilf\u00f8je nye funktioner, og det ville v\u00e6re lettere at omskrive hele programmet.<\/p>\n\n\n\n

Hvad er refaktorering?<\/h2>\n\n\n\n

Normalt er svaret, at det er at \u00e6ndre kodens struktur ved at anvende en r\u00e6kke refaktoriseringstransformationer uden at p\u00e5virke kodens observerbare adf\u00e6rd. Det er ogs\u00e5 rigtigt. For nylig st\u00f8dte jeg ogs\u00e5 p\u00e5 en definition af Martin Fowler<\/b> i sin bog \"Forbedring af designet af eksisterende regler\"<\/b> hvor han beskriver refaktorering<\/strong> som \"at lave store forandringer med sm\u00e5 skridt\". Han beskriver refaktorering<\/strong> som en kode\u00e6ndring, der ikke p\u00e5virker driften, men han understreger, at det skal ske i sm\u00e5 skridt.<\/p>\n\n\n\n

Bogen sl\u00e5r ogs\u00e5 til lyd for, at refaktorering<\/strong> ikke p\u00e5virker kodens funktion og p\u00e5peger, at det ikke har nogen effekt p\u00e5 at best\u00e5 testene p\u00e5 noget tidspunkt. Den beskriver trin for trin, hvordan man sikkert udf\u00f8rer refaktorering<\/strong>. Jeg kunne godt lide hans bog, fordi den beskriver enkle tricks, der kan bruges i det daglige arbejde.<\/p>\n\n\n\n

Hvorfor har vi brug for refaktorering?<\/h2>\n\n\n\n

 Oftest har du brug for det, n\u00e5r du vil indf\u00f8re en ny funktion, og koden i sin nuv\u00e6rende version ikke tillader det, eller det ville v\u00e6re sv\u00e6rere uden \u00e6ndringer i koden. Det er ogs\u00e5 nyttigt i tilf\u00e6lde, hvor det ikke er rentabelt tidsm\u00e6ssigt at tilf\u00f8je flere funktioner, dvs. at det ville v\u00e6re hurtigere at omskrive koden fra bunden. Jeg tror, at man nogle gange glemmer, at refaktorering<\/strong> kan g\u00f8re koden renere og mere l\u00e6sbar. Martin skriver i sin bog, hvordan han udf\u00f8rer refaktorering, n\u00e5r han f\u00f8ler ubehagelige lugte i koden, og, som han udtrykker det, \"Det giver altid plads til det bedre\"<\/b>. Og her overraskede han mig ved at se refaktorering som et element i det daglige kodearbejde. For mig er koderne ofte uforst\u00e5elige, og det er lidt af en oplevelse at l\u00e6se den, da koden ofte er uintuitiv.<\/p>\n\n\n\n

Det, der kendetegner et veldesignet program, er dets Modularitet<\/b>Takket v\u00e6re det er det nok kun at kende en lille del af koden for at indf\u00f8re de fleste \u00e6ndringer. Modularitet g\u00f8r det ogs\u00e5 lettere for nye folk at komme ind og begynde at arbejde mere effektivt. For at opn\u00e5 denne modularitet skal relaterede programelementer grupperes sammen, og forbindelserne skal v\u00e6re forst\u00e5elige og lette at finde. Der findes ikke en enkelt tommelfingerregel for, hvordan det kan g\u00f8res. Efterh\u00e5nden som du ved og forst\u00e5r mere og mere af, hvordan koden skal fungere, kan du gruppere elementerne, men nogle gange er du ogs\u00e5 n\u00f8dt til at teste og kontrollere.<\/p>\n\n\n\n

En af reglerne for refaktorering i YAGNI<\/b>Det er et akronym for 'You Aren't Gonna Need It' og stammer fra eXtreme programmering (XP) <\/b>bruges hovedsageligt i Agil<\/a> softwareudvikling<\/a> hold<\/strong>. Lang historie kort, YAGNI<\/b> siger, at kun aktuelle ting skal g\u00f8res. Det betyder dybest set, at selv om der kan blive brug for noget i fremtiden, skal det ikke g\u00f8res lige nu. Men vi kan heller ikke forhindre yderligere udvidelser, og det er her, modularitet bliver vigtig.<\/p>\n\n\n\n

N\u00e5r man taler om refaktorering<\/strong>skal et af de vigtigste elementer, nemlig test, n\u00e6vnes. I refaktorering<\/strong>er vi n\u00f8dt til at vide, at koden stadig virker, fordi refaktorering<\/strong> \u00e6ndrer ikke, hvordan den fungerer, men dens struktur, s\u00e5 alle tests skal best\u00e5s. Det er bedst at k\u00f8re tests for den del af koden, vi arbejder p\u00e5, efter hver lille transformation. Det giver os<\/a> en bekr\u00e6ftelse p\u00e5, at alt fungerer, som det skal, og det forkorter tiden for hele operationen. Det er det, Martin taler om i sin bog - k\u00f8r tests s\u00e5 ofte som muligt, s\u00e5 du ikke skal tr\u00e6de et skridt tilbage og spilde tid p\u00e5 at lede efter en transformation, der \u00f8delagde noget.<\/p>\n\n\n\n

Refaktorering af kode<\/a><\/strong> Uden test er det besv\u00e6rligt, og der er stor risiko for, at noget g\u00e5r galt. Hvis det er muligt, ville det v\u00e6re bedst at tilf\u00f8je i det mindste nogle grundl\u00e6ggende tests, der giver os lidt sikkerhed for, at koden fungerer.<\/p>\n\n\n\n

De transformationer, der er anf\u00f8rt nedenfor, er kun eksempler, men de er virkelig nyttige i den daglige programmering:<\/p>\n\n\n\n