Enkel refaktorering i C#: slik rydder du opp i rotete kode uten å ødelegge noe
Mange prosjekter starter pent og oversiktlig, men ender som en blanding av raske løsninger, midlertidige hacks og kopi-lim-kode. Da blir det vanskelig å gjøre endringer uten å være redd for å ødelegge noe.
I denne artikkelen ser vi på en enkel og trygg måte å refaktorere C#-kode på. Målet er å gi deg konkrete teknikker som gjør koden mer lesbar og lettere å vedlikeholde, uten store risikable omskrivinger.
Hva betyr refaktorering, og hvorfor bry seg?
Refaktorering betyr å endre strukturen i koden uten å endre hva programmet faktisk gjør. Du forbedrer innmaten, ikke funksjonaliteten utad. Når det gjøres riktig, vil brukeren ikke merke noe, men utvikleren får det mye enklere.
Fordelen er at du kan legge til nye funksjoner raskere, feilsøke lettere og redusere sjansen for skjulte feil. For små team og solo-utviklere kan god struktur være forskjellen mellom et prosjekt du styrer, og et prosjekt som styrer deg.
Start trygt: lag et lite sikkerhetsnett
Før du begynner å rydde, trenger du en måte å fange opp hvis noe går galt. Den enkleste varianten er noen få automatiserte tester eller manuelle sjekklister du kan kjøre hver gang du har gjort en endring.
Hvis du ikke bruker testverktøy ennå, kan du starte helt enkelt: lag en liten konsollapp eller egne metoder som kaller funksjonene dine med typiske inputverdier, og sjekk at resultatene stemmer før og etter refaktorering.
Identifiser typiske “lukt” i C#-koden din
Første steg er å se etter mønstre som ofte skaper problemer senere. Du trenger ikke avanserte verktøy, ditt eget ubehag når du leser koden er ofte et godt tegn på at noe bør ryddes.
Typiske tegn på at koden kan refaktoreres:
- Veldig lange metoder som gjør “alt mulig på én gang”.
- Mange kopier av nesten lik logikk ulike steder i prosjektet.
- Metoder med lange parameterlister som er vanskelige å huske og bruke rett.
- Kode med mange “magiske tall” og strenger som ingen helt husker betydningen av.
Første teknikk: trekk ut metode
En av de mest nyttige og tryggeste teknikkene i C# er å trekke ut deler av en metode til en egen metode med et godt navn. Dette gjør koden kortere, mer lesbar og enklere å teste.
Tenk at du har noe sånt i en tjenesteklasse:
Før:
public void ProcessOrder(Order order)
{
// Valider
if (order == null || order.Items == null || order.Items.Count == 0)
{
throw new ArgumentException("Invalid order");
}
// Beregn total
decimal total = 0;
foreach (var item in order.Items)
{
total += item.Price * item.Quantity;
}
// Logg
Console.WriteLine($"Processing order {order.Id} with total {total}");
}
Her gjør metoden tre forskjellige ting. Vi kan starte med å trekke ut validering og beregning:
Etter:
public void ProcessOrder(Order order)
{
ValidateOrder(order);
var total = CalculateTotal(order);
Console.WriteLine($"Processing order {order.Id} with total {total}");
}
private void ValidateOrder(Order order)
{
if (order == null || order.Items == null || order.Items.Count == 0)
{
throw new ArgumentException("Invalid order");
}
}
private decimal CalculateTotal(Order order)
{
decimal total = 0;
foreach (var item in order.Items)
{
total += item.Price * item.Quantity;
}
return total;
}
Funksjonaliteten er den samme, men nå er det mye tydeligere hva som skjer, og hver del kan videreutvikles eller testes separat.
Reduser duplisert logikk
Kopi-lim-kode fører ofte til feil som er vanskelige å finne, fordi du må huske å oppdatere samme logikk flere steder. Når du ser mye lik kode, er det et godt signal om at noe bør samles i én felles metode eller klasse.
En enkel fremgangsmåte når du finner duplikater:
- Marker de like delene og sjekk om de faktisk gjør akkurat det samme.
- Trekk ut felles kode til en metode med et generelt navn som gir mening for begge steder.
- Bytt ut de gamle kodestykkene med kall til den nye metoden.
Gjør parametere mer forståelige
Metoder med mange parametere er vanskelige å huske og lett å bruke feil. En vanlig forbedring i C# er å samle relaterte verdier i en egen klasse eller record, og sende det objektet inn i stedet.
Hvis du for eksempel har:
public void CreateUser(string firstName, string lastName, string email, bool isAdmin)
{
// ...
}
Kan du heller samle det slik:
public class UserCreateRequest
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public bool IsAdmin { get; set; }
}
public void CreateUser(UserCreateRequest request)
{
// ...
}
Det gir mer selvforklarende kode, og du kan enklere legge til flere felt senere uten å bryte alle kallene til metoden.
Gi ting navn som forklarer intensjonen
Noe av det mest effektive du kan gjøre når du refaktorerer, er å forbedre navn. Gode navn gjør ofte kommentarer overflødige og reduserer behovet for forklaring til andre (eller deg selv om tre måneder).
Noen enkle tommelfingerregler:
- Foretrekk navn som sierhvorfornoe gjør noe, ikke barehvordan.
- Unngå forkortelser som bare du skjønner, spesielt i offentlige API-er.
- La metoder som returnerer bool starte med “Is”, “Has” eller “Can” for tydeligere mening.
Refaktorer i små steg og test ofte
Det mest vanlige problemet ved opprydning er at man prøver å endre for mye på en gang. Da blir det vanskelig å se hva som faktisk brøt noe, og du mister oversikten.
En trygg rytme kan se slik ut: velg en liten del av koden, refaktorer én ting, kjør testene eller sjekklisten din, og gjør en commit. Da kan du alltid rulle tilbake hvis du har introdusert en feil.
Når bør du stoppe refaktoreringen?
Det er fristende å fortsette å “pusse” kode til alt ser perfekt ut, men i praksis er tiden begrenset. Et godt prinsipp er å refaktorere når du uansett er inne i koden for å gjøre en endring, ikke bare for opprydningens skyld.
Spør deg selv: Vil denne endringen gjøre det enklere å forstå og endre denne delen neste gang jeg er her? Hvis svaret er ja, er det sannsynligvis verdt innsatsen. Hvis svaret er nei, er det kanskje bedre å la det ligge.
Oppsummering: bygg vane, ikke perfekt arkitektur
Refaktorering er ikke en engangsaktivitet, men en vane. Med små, trygge steg som å trekke ut metoder, redusere duplikatkode, samle parametere og forbedre navn, kan du gradvis gjøre C#-prosjektene dine mer robuste uten risiko for store krasj.
Start med én fil du ofte plages med. Gi deg selv et lite sikkerhetsnett med tester, gjør en konkret forbedring og se hvordan det føles å jobbe i koden etterpå. Den erfaringen er den beste guiden til hva du bør rydde opp i neste gang.
0 kommentarer