{"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-snabb-introduktion-till-refaktorisering-for-nyborjare","status":"publish","type":"post","link":"https:\/\/thecodest.co\/sv\/blog\/a-quick-primer-on-refactoring-for-beginners\/","title":{"rendered":"En snabb introduktion till refaktorisering f\u00f6r nyb\u00f6rjare"},"content":{"rendered":"

D\u00e4rf\u00f6r \u00e4r det obegripligt f\u00f6r vissa att Refaktorisering<\/strong> \u00e4r faktiskt ett omr\u00e5de inom programmering, och det \u00e4r ocks\u00e5 en mycket viktig del av programmerarens arbete. Koden \u00e4r i st\u00e4ndig utveckling, den kommer att modifieras s\u00e5 l\u00e4nge det finns m\u00f6jlighet att l\u00e4gga till nya funktioner. Den kan dock anta en form som inte l\u00e4ngre g\u00f6r det m\u00f6jligt att effektivt l\u00e4gga till nya funktioner och det skulle d\u00e5 vara enklare att skriva om hela programmet.<\/p>\n\n\n\n

Vad \u00e4r refaktorisering?<\/h2>\n\n\n\n

Vanligtvis f\u00e5r man svaret att det handlar om att \u00e4ndra kodens struktur genom att till\u00e4mpa en serie refaktoriseringstransformationer utan att p\u00e5verka kodens observerbara beteende. Detta \u00e4r sant. Nyligen kom jag ocks\u00e5 \u00f6ver en definition av Martin Fowler<\/b> i sin bok \"F\u00f6rb\u00e4ttra utformningen av befintlig kod\"<\/b> d\u00e4r han beskriver Refaktorisering<\/strong> som \"att g\u00f6ra stora f\u00f6r\u00e4ndringar i sm\u00e5 steg\". Han beskriver Refaktorisering<\/strong> som en kod\u00e4ndring som inte p\u00e5verkar dess funktion, men han betonar att det m\u00e5ste g\u00f6ras i sm\u00e5 steg.<\/p>\n\n\n\n

Boken f\u00f6respr\u00e5kar ocks\u00e5 att Refaktorisering<\/strong> inte p\u00e5verkar kodens funktion och p\u00e5pekar att det inte har n\u00e5gon effekt p\u00e5 att klara testerna vid n\u00e5gon tidpunkt. Den beskriver steg f\u00f6r steg hur man p\u00e5 ett s\u00e4kert s\u00e4tt utf\u00f6r Refaktorisering<\/strong>. Jag gillade hans bok eftersom den beskriver enkla knep som kan anv\u00e4ndas i det dagliga arbetet.<\/p>\n\n\n\n

Varf\u00f6r beh\u00f6ver vi refaktorisering?<\/h2>\n\n\n\n

 Oftast kan du beh\u00f6va det n\u00e4r du vill inf\u00f6ra en ny funktionalitet och koden i sin nuvarande version inte till\u00e5ter det eller det skulle vara sv\u00e5rare utan \u00e4ndringar i koden. Det \u00e4r ocks\u00e5 anv\u00e4ndbart i fall d\u00e4r det \u00e4r ol\u00f6nsamt tidsm\u00e4ssigt att l\u00e4gga till fler funktioner, det vill s\u00e4ga att det skulle vara snabbare att skriva om koden fr\u00e5n grunden. Jag tror att det ibland gl\u00f6ms bort att Refaktorisering<\/strong> kan g\u00f6ra koden renare och mer l\u00e4sbar. Martin skriver i sin bok hur han utf\u00f6r refaktorisering n\u00e4r han k\u00e4nner obehagliga lukter i koden och, som han uttrycker det, \"det l\u00e4mnar alltid utrymme f\u00f6r det b\u00e4ttre\"<\/b>. Och han \u00f6verraskade mig h\u00e4r genom att se refaktorisering som en del av det dagliga kodarbetet. F\u00f6r mig \u00e4r koderna ofta obegripliga, att l\u00e4sa den \u00e4r lite av en upplevelse eftersom koden ofta \u00e4r ointuitiv.<\/p>\n\n\n\n

Det som utm\u00e4rker ett v\u00e4l utformat program \u00e4r dess Modularitet<\/b>Tack vare detta r\u00e4cker det med att k\u00e4nna till en liten del av koden f\u00f6r att g\u00f6ra de flesta \u00e4ndringar. Modularitet g\u00f6r det ocks\u00e5 l\u00e4ttare f\u00f6r nya personer att komma in och b\u00f6rja arbeta mer effektivt. F\u00f6r att uppn\u00e5 denna modularitet m\u00e5ste relaterade programelement grupperas tillsammans, och kopplingarna m\u00e5ste vara begripliga och l\u00e4tta att hitta. Det finns ingen enskild tumregel f\u00f6r hur detta kan g\u00f6ras. Allt eftersom du vet och f\u00f6rst\u00e5r mer och mer av hur koden \u00e4r t\u00e4nkt att fungera b\u00e4ttre kan du gruppera elementen, men ibland m\u00e5ste du ocks\u00e5 testa och kontrollera.<\/p>\n\n\n\n

En av reglerna f\u00f6r refaktorisering i YAGNI<\/b>\u00e4r en akronym f\u00f6r \"You Aren't Gonna Need It\" och h\u00e4rstammar fr\u00e5n eXtreme-programmering (XP) <\/b>anv\u00e4nds fr\u00e4mst i Agil<\/a> Utveckling av programvara<\/a> lag<\/strong>. F\u00f6r att g\u00f6ra en l\u00e5ng historia kort, YAGNI<\/b> s\u00e4ger att endast aktuella saker ska g\u00f6ras. Det betyder i princip att \u00e4ven om n\u00e5got kan beh\u00f6vas i framtiden, s\u00e5 ska det inte g\u00f6ras just nu. Men vi kan inte heller krossa ytterligare till\u00e4gg och det \u00e4r h\u00e4r modularitet blir viktigt.<\/p>\n\n\n\n

N\u00e4r man talar om Refaktorisering<\/strong>m\u00e5ste ett av de viktigaste inslagen n\u00e4mnas, n\u00e4mligen testerna. I Refaktorisering<\/strong>m\u00e5ste vi veta att koden fortfarande fungerar, eftersom Refaktorisering<\/strong> \u00e4ndrar inte hur den fungerar, utan dess struktur, s\u00e5 alla tester m\u00e5ste godk\u00e4nnas. Det \u00e4r b\u00e4st att k\u00f6ra tester f\u00f6r den del av koden som vi arbetar med efter varje liten f\u00f6r\u00e4ndring. Det ger oss<\/a> en bekr\u00e4ftelse p\u00e5 att allt fungerar som det ska och det f\u00f6rkortar tiden f\u00f6r hela operationen. Det \u00e4r detta som Martin pratar om i sin bok - k\u00f6r tester s\u00e5 ofta som m\u00f6jligt f\u00f6r att inte beh\u00f6va ta ett steg tillbaka och sl\u00f6sa tid p\u00e5 att leta efter en transformation som f\u00f6rst\u00f6rde n\u00e5got.<\/p>\n\n\n\n

Refaktorisering av kod<\/a><\/strong> utan testning \u00e4r jobbigt och det finns en stor risk att n\u00e5got g\u00e5r fel. Om det \u00e4r m\u00f6jligt \u00e4r det b\u00e4st att l\u00e4gga till \u00e5tminstone n\u00e5gra grundl\u00e4ggande tester som ger oss en liten f\u00f6rs\u00e4kran om att koden fungerar.<\/p>\n\n\n\n

De omvandlingar som anges nedan \u00e4r endast exempel men de \u00e4r till stor hj\u00e4lp vid daglig programmering:<\/p>\n\n\n\n