Grunnleggende kodeorganisering: slik bygger du små prosjekter som er enkle å videreutvikle

Det er gøy å få første versjon av et lite program til å fungere, helt til du kommer tilbake tre uker senere og ikke skjønner hva du selv har laget. Da blir små endringer fort til store frustrasjoner.

God kodeorganisering handler om å gjøre livet ditt enklere: enklere å endre, feilsøke og bygge videre på. Her ser vi på enkle, konkrete grep du kan ta allerede i dag, selv i veldig små prosjekter.

Start med å dele opp: ett ansvar per fil

En vanlig felle i små prosjekter er å legge all logikk i én stor fil. Det virker raskt i starten, men blir raskt uoversiktlig når du skal legge til flere funksjoner, jobbe med data fra flere kilder eller feilsøke en konkret del.

Et godt utgangspunkt er å la hver fil ha ett hovedansvar. Det gjør det lettere å finne igjen ting, og du slipper å være redd for å ødelegge andre deler når du endrer logikk i én del.

En enkel mappestruktur for små prosjekter

La oss si du lager et lite kommandolinjeverktøy som henter data fra et API, lagrer til en fil og viser en enkel rapport. Da kan en første fornuftig struktur se slik ut (språket spiller ingen rolle):

• main: starter programmet og kobler delene sammen
• api: alt som har med eksterne forespørsler å gjøre
• storage: lagring til fil eller database
• report: generering og visning av rapporter

Poenget er ikke navnene i seg selv, men at du deler etter oppgave. Når du vil endre hvordan rapporten ser ut, går du til rapport-delen, ikke til en tilfeldig linje i en stor fil.

Gi funksjoner og variabler tydelige navn

Navn er en stor del av kodeorganisering. Dårlige navn gjør at du må lese hele funksjonen for å forstå hva som skjer. Gode navn gjør at du kan skumlese og likevel få oversikt.

Prøv å navngi ting etter hensikten, ikke typen. Da blir koden mer selvforklarende, og du trenger færre kommentarer for å forklare hva som skjer.

Enkle tommelfingerregler for gode navn

• Funksjoner: beskriv hva de gjør, somcalculate_totali stedet fordo_calc.
• Variabler: beskriv hva de inneholder, somuser_counti stedet forx.
• Boolske verdier: bruk navn som kan besvares med ja eller nei, somis_validellerhas_errors.
• Samlinger: bruk flertall, somusersellerorders.

Hvis du sliter med å finne et navn, kan det være et tegn på at funksjonen gjør for mye. Prøv da å dele den opp i mindre biter med klarere ansvar.

Lag små, gjenbrukbare funksjoner

Mange starter med én lang funksjon som gjør alt: henter data, filtrerer, beregner, logger og skriver ut. Det fungerer til det ikke gjør det lenger, for eksempel når du vil teste bare én av delene eller bruke logikken et annet sted.

Et godt grep er å dele opp etter steg i prosessen. Tenk «hent data», «behandle data» og «vis resultat» som egne funksjoner, ikke som kommentarer inne i én blokklignende funksjon.

Et konkret eksempel på oppdeling

Tenk deg at du vil behandle en liste av tall: filtrere bort negative, regne ut gjennomsnitt og skrive ut resultatet. I stedet for én funksjon som gjør alt, kan du dele det slik:

• filter_valid_numbers(): tar inn en liste, returnerer bare de gyldige tallene
• calculate_average(): tar inn tallene, returnerer gjennomsnitt
• print_summary(): tar inn resultatet, skriver noe pent til skjermen

Fordelen er at du kan teste hver del for seg, gjenbruke logikken i andre sammenhenger, og lettere se hvor en eventuell feil oppstår.

Bruk mapper til å skille «kjerne» fra «ytre lag»

Selv i små prosjekter kan det være nyttig å skille mellom selve forretningslogikken og omgivelsene rundt, som brukergrensesnitt, API-kall eller database. Da blir det enklere å bytte ut det ytre laget senere, uten å omskrive alt.

En enkel måte å tenke på er å ha en mappe for «core» eller «domain», som inneholder ren logikk uten kunnskap om hvor data kommer fra, og egne mapper for ting som web, CLI eller lagring.

Hvorfor dette gir mer fleksibel kode

Hvis kjernen din kan jobbe med enkle datatyper eller egne små dataobjekter, kan du senere:

• Bytte fra kommandolinje til webgrensesnitt uten å røre beregningene.
• Bytte database eller filformat ved å endre kun lagringsdelen.
• Skrive tester som bare bruker kjernelogikken, uten å måtte sette opp hele «omverdenen».

Du trenger ikke et stort rammeverk for å få dette til. Det holder å være bevisst på at kjernen ikke skal være avhengig av detaljer som HTTP-forespørsler eller SQL-spørringer.

Lag enkle konvensjoner for deg selv

Du trenger ikke følge en tung standard for å ha nytte av konvensjoner. Poenget er å gjøre det forutsigbart hvor ting ligger, og hva filer og funksjoner heter. Da slipper du å tenke på struktur hver gang du legger til noe nytt.

Start i det små, for eksempel med noen få regler du faktisk klarer å følge over tid, og juster dem etter hvert som du ser hva som fungerer og ikke.

Forslag til egne konvensjoner i små prosjekter

• Alle filer som starter programmet hetermaineller liknende.
• Funksjoner som kan gjenbrukes, legges i egne filer, ikke i programstart-filen.
• Testing, midlertidige skript og eksperimenter havner i en egenplaygroundellerscratch-mappe.
• Navngivning følger samme mønster i hele prosjektet, for eksempel engelsk på alt, ikke blanding.

Det viktige er at du skriver ned konvensjonene, selv om det bare er i en kort tekstfil. Da har du noe å lene deg på når prosjektet vokser.

Slik kan du begynne å rydde i et eksisterende prosjekt

Hvis du allerede har rotete kode, er det lett å tenke at du må skrive alt på nytt. Det er sjelden nødvendig, og ofte en dårlig idé. Det er bedre å rydde litt og litt mens du gjør endringer du likevel trenger.

En enkel strategi er å flytte ut én ting av gangen: en funksjon, en gruppe relaterte funksjoner, eller logikk som tydelig hører sammen. Test etter hvert flytt, så du ikke introduserer nye feil.

En trinnvis tilnærming til refaktorering

1. Finn et område du ofte er innom, for eksempel rapportgenerering.
2. Identifiser funksjoner eller kodeblokker som hører sammen.
3. Flytt dem til en egen fil med et godt navn, for eksempelreport.
4. Oppdater import eller kall der de ble brukt, og test at alt fungerer.
5. Gjenta neste gang du likevel endrer noe i en annen del av koden.

Over tid vil prosjektet bli stadig mer ryddig, uten at du trenger å stoppe all utvikling for å «skrive alt på nytt».

Oppsummering: gjør det lett for «fremtidens deg»

Kodeorganisering handler til syvende og sist om å være snill mot deg selv om noen uker eller måneder. Tenk på at «fremtidens deg» ikke nødvendigvis husker hvorfor du valgte akkurat den løsningen eller hvor ting ligger.

Hvis du deler opp i filer med tydelig ansvar, gir navn som sier hva ting gjør, lager små gjenbrukbare funksjoner og har en enkel mappe- og navnekonvensjon, har du allerede tatt store steg mot kode som er mye enklere å forstå og videreutvikle.