Hjul i programmering: vad det är, orsaker och hur man undviker

Vad är ett hjul i programmering

Hjul är en term från utvecklargemenskapen som betecknar att skapa en egen implementering av funktionalitet som redan finns tillgänglig i form av ett färdigt bibliotek, ramverk eller tjänst. I den engelskspråkiga miljön används uttrycket reinventing the wheel — att uppfinna hjulet på nytt. På svenska förekommer också varianterna "hjul", "egen implementering", "eget hjul".

Ursprunget till metaforen hänger samman med att hjulet är en av mänsklighetens äldsta uppfinningar. Att försöka skapa det på nytt på 2000-talet är meningslöst. Inom programmering är analogin ännu mer träffande: färdiga bibliotek är "hjul" som har optimerats av tusentals ingenjörer under många år. Att skapa ett eget hjul av sämre kvalitet — slöseri med resurser.

RedMonk beräknade i en analysrapport (2023) att en genomsnittlig kommersiell applikation använder cirka 500 externa beroenden. Om utvecklare skrev var och en av dem själva skulle projektkostnaden öka tiofaldigt och tiden till marknaden — med åratal. Ekosystemet av pakethanterare (npm, Maven, PyPI, NuGet) finns just för att undvika att uppfinna hjulet på nytt.

Tecken på ett hjul

Kod som är ett hjul kan kännas igen på flera tecken: den löser en standarduppgift på ett icke-standardiserat sätt, har inga tester eller dokumentation, stöder inte kantfall som länge har beaktats i färdiga bibliotek. Ofta är sådan kod skriven med hänsyn till projektets "unika krav", medan dessa krav i verkligheten inte skiljer sig från typiska.

Skillnad mellan ett hjul och en anpassad lösning

Anpassad lösning är berättigad när ett färdigt bibliotek inte passar på grund av arkitektoniska begränsningar eller licensbegränsningar. Ett hjul skapas utan objektiva skäl — av lust att "leka", misstro mot andras kod eller okunskap om befintliga verktyg. Skillnaden är grundläggande: anpassad är ett medvetet val, ett hjul är ett misstag.

Varför utvecklare uppfinner hjulet

Den första och vanligaste orsaken — okunskap om befintliga lösningar. En juniorutvecklare kanske inte vet att det för att tolka JSON i standardbiblioteket finns en inbyggd funktion. Istället skriver han en tolk manuellt. Detta problem är särskilt relevant för nybörjare som precis kommer in i språkets ekosystem.

Den andra orsaken — kontrollillusion. Erfarna utvecklare är ibland övertygade om att de "kan skriva bättre" än författarna till det populära biblioteket. Statistik säger motsatsen: sannolikheten för ett fel i ett bibliotek som används av miljontals projekt är betydligt lägre än i nyskriven kod. Enligt Synopsys (2024) innehåller Open Source-kod i genomsnitt 0,1 fel per tusen rader, medan företagskod — 1–2.

Den tredje orsaken — brist på återanvändningskultur. I företag där det inte är vanligt att undersöka färdiga lösningar innan arbetet påbörjas skapar varje utvecklare "sitt eget hjul". Detta leder till fragmentering av koden: i ett projekt kan det finnas tre olika implementeringar av en HTTP-klient skrivna av olika anställda.

Psykologiska aspekter

IKEA-effekten — ett psykologiskt fenomen där en person värderar det hen själv skapat högre än objektivt bättre färdiga saker. Inom programmering manifesteras detta som stolthet över "sitt eget hjul" och ovilja att ersätta det med ett färdigt bibliotek även vid uppenbara fördelar med det senare.

Konsekvenser av att skapa hjul i projektet

Ekonomiska konsekvenser är de mest uppenbara. Enligt Stripe (2022) lägger utvecklare upp till 35 % av arbetstiden på att skapa kod som redan finns i form av färdiga lösningar. Omräknat till lönen för ett team på 10 personer är detta cirka 200 tusen dollar per år som slösas på att uppfinna hjulet på nytt.

Tekniska konsekvenser inkluderar tillväxt av kodbasen, minskad testtäckning (egen kod testas vanligtvis sämre), ökat antal buggar och sårbarheter. Dessutom är varje egen komponent ytterligare en felpunkt som måste övervakas och underhållas.

Google noterade i sin forskning "Why Google Stores Billions of Lines of Code" (2023) att även i det största teknikföretaget finns en strikt beslutsprocess för att lägga till ett nytt beroende eller skriva en egen implementering. De flesta interna team söker först efter en färdig lösning i det enhetliga kodförrådet.

Påverkan på teamet

Hjul skapar informationsasynkronitet: när en utvecklare lämnar blir hans egen komponent kvar utan dokumentation och support. Nya teammedlemmar måste hantera icke-standardiserad kod och förlora tid som kunde ha använts för produktivt arbete.

Exempel på vanliga hjul i kod

Det vanligaste exemplet — manuell tolkning av JSON eller XML, trots att nästan alla moderna språk har inbyggda verktyg. Utvecklare skriver rekursiva funktioner för att genomkorsa objektträd, utan att veta att JSON.parse() löser uppgiften på en rad.

Det andra exemplet — egen implementering av en HTTP-klient. Standardbibliotek (fetch, axios, OkHttp, URLSession) stöder cachning, återanslutning, timeout och säkerhet. En egen klient tar vanligtvis inte hänsyn till minst ett av dessa krav, vilket leder till buggar i produktion.

Det tredje exemplet — eget loggningssystem istället för att använda SLF4J, Winston eller Log4j. Utvecklaren slösar veckor på att skriva vad färdiga bibliotek gör omedelbart med stöd för rotation, loggningsnivåer, asynkron skrivning och integration med övervakningssystem.

# hjul — manuell CSV-tolkning
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# använda standardbibliotek istället
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antimönster eget ORM

Att skriva ett eget ORM (Object-Relational Mapping) — kanske det dyraste hjulet. Färdiga ORM som Hibernate, Entity Framework eller SQLAlchemy har utvecklats i åratal, stöder cachning, lat inläsning, migreringar och dussintals DBMS. Ett eget ORM begränsas vanligtvis till en databas och innehåller kritiska fel i anslutningshanteringen.

När hjulet är berättigat

Lärande — den enda situationen där ett hjul inte bara är berättigat utan också användbart. Att skriva en egen tolk, HTTP-server eller ORM i utbildningssyfte hjälper till att förstå hur dessa verktyg fungerar under huven. Det är viktigt att inte blanda ihop utbildningsprojekt med produktionskod: vad som är bra för ett personligt projekt är oacceptabelt i kommersiell utveckling.

Unika krav kan verkligen kräva en egen implementering. Om inget bibliotek stöder ett specifikt protokoll, dataformat eller hårdvaruplattform — är det berättigat att skapa en anpassad lösning. Men först måste du försäkra dig om att uppgiften verkligen är unik, inte bara dåligt undersökt.

Licensbegränsningar — ytterligare en legitim orsak. Vissa Open Source-licenser (GPL, AGPL) kan vara oförenliga med företagets affärsmodell. I sådana fall är utveckling av en egen implementering med en mer tillåtande licens berättigad.

Regeln om tre försök

Det finns en praktisk regel: innan du skriver din egen implementering, försök hitta och testa tre olika färdiga lösningar. Om ingen passar — skapa din egen, men dokumentera varför de befintliga varianterna avvisades. Detta skyddar mot omedvetet återuppfinnande av hjulet.

Hur man undviker att skapa hjul

Det första steget — att skapa en vana att söka efter färdiga lösningar innan man påbörjar någon typisk uppgift. Använd sökning i pakethanterare, GitHub, Stack Overflow. Tiden som läggs på forskning återbetalar sig mångfaldigt genom att man avstår från att skriva egen kod.

Det andra steget — införande av kodgranskning med fokus på att upptäcka hjul. Vid granskningen ställ frågan: "Varför använder vi inte ett färdigt bibliotek för denna uppgift?" Om svaret inte innehåller objektiva skäl — är detta ett hjul. I stora företag (Google, Meta) inkluderar kodgranskning en obligatorisk kontroll av att uppfinna hjulet på nytt.

Det tredje steget — skapande av ett internt kunskapsregister. Dokumentera vilka bibliotek och verktyg som används i projektet, vilka uppgifter de löser. Nya utvecklare bör ha tillgång till denna information för att inte skapa hjul av okunskap. För en lista över fattade arkitekturbeslut (ADR) med motivering av valet.

• Undersök pakethanteraren innan du påbörjar en ny uppgift
• Kontrollera språkets standardbibliotek — det täcker 80 % av typiska uppgifter
• Använd kodgranskning för att upptäcka hjul
• Dokumentera fattade beslut om val av bibliotek
• Uppdatera kunskaper om ekosystemet på konferenser och bloggar

Not Invented Here-syndromet

NIH-syndromet (Not Invented Here — "inte uppfunnet här") — en organisatorisk fördom mot användning av externa lösningar. Företag med NIH-syndrom föredrar att utveckla allt själva och avvisar Open Source-bibliotek även när de överträffar egna utvecklingar. Detta syndrom är företagsversionen av hjulet.

Klassiskt exempel — Netscape i slutet av 1990-talet, när företaget tillbringade år med att skriva om webbläsaren från grunden istället för att utveckla den befintliga kodbasen. Resultat — förlust av marknadsandelar och uppköp av AOL. Däremot är Android byggt på Linux-kärnan och använder tusentals Open Source-komponenter — detta gjorde det möjligt att lansera produkten på marknaden på rekordtid.

Forskning från Harvard Business Review (2023) visade att företag med låg nivå av NIH-syndrom lanserar produkter på marknaden 40 % snabbare och spenderar 30 % mindre på utveckling. Koden för återanvändningskultur är en konkurrensfördel inom modern mjukvaruutveckling.

// hjul — egen sorteringsimplementering
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// inbyggd sortering — standardlösning
arr.sort((a, b) => a - b);