{"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-rask-innforing-i-refaktorering-for-nybegynnere","status":"publish","type":"post","link":"https:\/\/thecodest.co\/nb\/blog\/a-quick-primer-on-refactoring-for-beginners\/","title":{"rendered":"En rask innf\u00f8ring i refaktorering for nybegynnere"},"content":{"rendered":"

Derfor er det uforst\u00e5elig for noen at refaktorisering<\/strong> er faktisk et omr\u00e5de innen programmering, og det er ogs\u00e5 en sv\u00e6rt viktig del av programmererens arbeid. Koden er i stadig utvikling, og den vil bli endret s\u00e5 lenge det er mulig \u00e5 legge til ny funksjonalitet. Det kan imidlertid hende at den tar en form som ikke lenger gj\u00f8r det mulig \u00e5 legge til ny funksjonalitet p\u00e5 en effektiv m\u00e5te, og da er det enklere \u00e5 skrive om hele programmet.<\/p>\n\n\n\n

Hva er refaktorisering?<\/h2>\n\n\n\n

Vanligvis f\u00e5r du til svar at det dreier seg om \u00e5 endre strukturen i koden ved \u00e5 bruke en rekke refaktoriseringstransformasjoner uten \u00e5 p\u00e5virke kodens observerbare atferd. Dette er sant. Nylig kom jeg ogs\u00e5 over en definisjon av Martin Fowler<\/b> i sin bok \"Forbedring av utformingen av eksisterende kodeverk\"<\/b> hvor han beskriver refaktorisering<\/strong> som \"\u00e5 gj\u00f8re store endringer med sm\u00e5 skritt\". Han beskriver refaktorisering<\/strong> som en kodeendring som ikke p\u00e5virker driften, men han understreker at det m\u00e5 gj\u00f8res i sm\u00e5 skritt.<\/p>\n\n\n\n

Boken tar ogs\u00e5 til orde for at refaktorisering<\/strong> ikke p\u00e5virker driften av koden, og p\u00e5peker at det ikke har noen innvirkning p\u00e5 best\u00e5tt test p\u00e5 noe tidspunkt. Den beskriver trinn for trinn hvordan du trygt kan utf\u00f8re refaktorisering<\/strong>. Jeg likte boken fordi den beskriver enkle triks som kan brukes i det daglige arbeidet.<\/p>\n\n\n\n

Hvorfor trenger vi refaktorisering?<\/h2>\n\n\n\n

 Oftest trenger du det n\u00e5r du \u00f8nsker \u00e5 introdusere en ny funksjonalitet og koden i sin n\u00e5v\u00e6rende versjon ikke tillater det, eller det ville v\u00e6re vanskeligere uten endringer i koden. Det er ogs\u00e5 nyttig i tilfeller der det er ul\u00f8nnsomt \u00e5 legge til flere funksjoner, det vil si at det ville v\u00e6re raskere \u00e5 skrive om koden fra bunnen av. Jeg tror det noen ganger glemmes at refaktorisering<\/strong> kan gj\u00f8re koden renere og mer lesbar. Martin skriver i boken sin hvordan han utf\u00f8rer refaktorering n\u00e5r han kjenner ubehagelig lukt i koden, og, som han uttrykker det, \"det gir alltid rom for det bedre\"<\/b>. Og han overrasket meg her ved \u00e5 se refaktorering som et element i det daglige kodearbeidet. For meg er kodene ofte uforst\u00e5elige, det er litt av en opplevelse \u00e5 lese den fordi koden ofte er uintuitiv.<\/p>\n\n\n\n

Det som kjennetegner et godt utformet program, er dets modularitet<\/b>Det er derfor nok \u00e5 kunne bare en liten del av koden for \u00e5 kunne gj\u00f8re de fleste endringer. Modularitet gj\u00f8r det ogs\u00e5 lettere for nye personer \u00e5 komme inn og begynne \u00e5 jobbe mer effektivt. For \u00e5 oppn\u00e5 denne modulariteten m\u00e5 beslektede programelementer grupperes sammen, og forbindelsene m\u00e5 v\u00e6re forst\u00e5elige og lette \u00e5 finne. Det finnes ingen tommelfingerregel for hvordan dette kan gj\u00f8res. Etter hvert som du vet og forst\u00e5r mer og mer av hvordan koden er ment \u00e5 fungere, kan du gruppere elementene bedre, men noen ganger m\u00e5 du ogs\u00e5 teste og sjekke.<\/p>\n\n\n\n

En av reglene for refaktorering i YAGNI<\/b>Det er et akronym for \"You Aren't Gonna Need It\" og stammer fra eXtreme-programmering (XP) <\/b>hovedsakelig brukt i Smidig<\/a> programvareutvikling<\/a> lag<\/strong>. For \u00e5 gj\u00f8re en lang historie kort, YAGNI<\/b> sier at bare oppdaterte ting skal gj\u00f8res. Det betyr at selv om noe kan bli n\u00f8dvendig i fremtiden, b\u00f8r det ikke gj\u00f8res akkurat n\u00e5. Men vi kan heller ikke knuse ytterligere utvidelser, og det er her modularitet blir viktig.<\/p>\n\n\n\n

N\u00e5r man snakker om refaktorisering<\/strong>m\u00e5 et av de viktigste elementene, nemlig testene, nevnes. I refaktorisering<\/strong>m\u00e5 vi vite at koden fortsatt fungerer, fordi refaktorisering<\/strong> endrer ikke hvordan den fungerer, men strukturen, s\u00e5 alle tester m\u00e5 best\u00e5s. Det beste er \u00e5 kj\u00f8re tester for den delen av koden vi jobber med, etter hver lille transformasjon. Det gir oss<\/a> en bekreftelse p\u00e5 at alt fungerer som det skal, og det forkorter tiden for hele operasjonen. Det er dette Martin snakker om i boken sin - kj\u00f8r tester s\u00e5 ofte som mulig for ikke \u00e5 ta et skritt tilbake og kaste bort tid p\u00e5 \u00e5 lete etter en transformasjon som \u00f8dela noe.<\/p>\n\n\n\n

Refaktorisering av kode<\/a><\/strong> Uten testing er det vanskelig, og det er stor sjanse for at noe g\u00e5r galt. Hvis det er mulig, er det best \u00e5 legge til i det minste noen grunnleggende tester som gir oss en liten forsikring om at koden fungerer.<\/p>\n\n\n\n

Transformasjonene nedenfor er bare eksempler, men de er sv\u00e6rt nyttige i den daglige programmeringen:<\/p>\n\n\n\n