IT-ordbog for ikke-udviklere: 60 begreber forklaret

Her får du 60 IT-begreber forklaret på almindeligt dansk, fra API og MVP til staging, teknisk gæld og databehandleraftale. Ordbogen er til dig der skal købe, styre eller tale med en udvikler uden selv at være teknisk, og hver forklaring siger kort hvad ordet betyder for din tid, pris eller risiko.

Jeg er selv freelanceudvikler, så forklaringerne bygger på hvordan jeg bruger ordene. Andre udviklere bruger enkelte ord lidt anderledes, og det er i sig selv en god grund til at spørge.

Den korte version

Har du kun to minutter, så er det disse seks begreber der oftest påvirker pris og risiko i et projekt. Højre kolonne er det spørgsmål jeg selv ville stille hvis jeg sad på din side af bordet.

Min tommelfingerregel: forstår du ikke et ord i et tilbud, så spørg før du skriver under. Vil du se hvor begreberne hører hjemme i et samlet forløb, så læs min gennemgang af et udviklingsprojekt fra idé til drift.

Opbygning og teknologi

Ordene her beskriver hvad et system består af. Du skal ikke vælge teknologien selv, men det hjælper at forstå hvad udvikleren foreslår.

Frontend

Den del af systemet som brugeren ser og klikker i: sider, knapper og formularer. Den kører i browseren. Typiske værktøjer er React, Vue og Tailwind CSS.

Backend

Den del der kører på serveren, og som brugeren ikke ser: forretningsregler, beregninger, login og kontakten til databasen. Er frontenden butikken, er backenden lageret og kontoret bagved.

Fullstack

En udvikler der arbejder med både frontend og backend, og som derfor kan have overblikket i mindre og mellemstore projekter. Jeg er selv fullstack-udvikler. Rollerne har jeg sammenlignet i frontend, backend eller fullstack.

Database

Stedet hvor systemets data bliver gemt i en fast struktur, fx kunder, ordrer og bookinger. Mange webapps bruger MySQL eller PostgreSQL. Databasen er tit det mest værdifulde i dit system.

API

En aftalt måde for to systemer at tale sammen på, fx når din webshop henter lagerstatus fra dit lagersystem. Jeg har skrevet en hel artikel om hvad et API er, og hvorfor dit system har brug for et.

Integration

En kobling mellem to systemer, typisk via et API, så data flyder automatisk i stedet for at blive tastet ind to gange. Spørg altid hvad der sker når det andet system er nede.

Webhook

En besked som et system automatisk sender til et andet når noget sker, fx når en betaling er gennemført. Et API svarer når man spørger. En webhook giver besked af sig selv.

Framework

Et færdigt fundament af kode som udvikleren bygger videre på, så login og sikkerhed ikke skal opfindes fra bunden. Laravel og Next.js er eksempler. Et udbredt framework gør det lettere at finde en ny udvikler senere.

Tech stack

Den samlede kombination af teknologier et system er bygget med: sprog, framework, database og hosting. Min egen er typisk Laravel, React og Tailwind CSS. Jeg har forklaret hvad en tech stack er, uden jargon.

Webapp

Et program der kører i browseren og kan mere end en hjemmeside: brugere logger ind, data bliver gemt, og der er arbejdsgange. Kundeportaler og bookingsystemer er typiske webapps.

Native app og PWA

En native app er bygget til iPhone eller Android og hentes i en app-butik. En PWA (progressive web app) er en webapp der kan lægges på hjemmeskærmen. Den er ofte billigere, fordi der kun er én kodebase.

SaaS

Software as a service: software du betaler abonnement for og bruger i browseren uden at installere den. Udbyderen står for drift og opdateringer.

Monolit og microservices

En monolit er ét samlet system. Microservices er mange små systemer der taler sammen. Microservices passer til meget store systemer med mange teams. For de fleste projekter er en velorganiseret monolit billigere og enklere.

Open source

Kode som alle frit må bruge, læse og som regel ændre, under en bestemt licens. Laravel og React er open source. Du betaler ikke licens for værktøjerne, men stadig for tiden det tager at bygge med dem.

Projekt og samarbejde

Disse ord møder du i første møde og i tilbuddet. De afgør hvad du får, hvornår, og hvad det koster.

MVP

Minimum viable product: den mindste version af et produkt som rigtige brugere kan bruge og give feedback på. En god MVP løser én opgave ordentligt i stedet for mange opgaver halvt.

Proof of concept (PoC)

En hurtig test af om en teknisk idé kan lade sig gøre, fx om to systemer kan tale sammen. Koden smides ofte væk bagefter. Formålet er at fjerne den største usikkerhed tidligt.

Wireframe og prototype

En wireframe er en grov skitse af en skærm. En prototype er en klikbar model, typisk lavet i Figma. Begge er billige at ændre, og det er pointen: rettelser koster mindre før koden bliver skrevet.

Forprojekt (discovery)

Et kort, afgrænset forløb før udviklingen hvor krav, risici og pris bliver afklaret. Resultatet er en prioriteret funktionsliste og et sikrere estimat. Før større opgaver laver jeg et betalt forprojekt til fast pris.

Kravspecifikation

Et dokument der beskriver hvad systemet skal kunne, hvem der bruger det, og hvilke regler det skal følge. Den behøver ikke være lang. Jeg har skrevet en guide til hvordan du skriver en kravspecifikation, med en gratis skabelon.

User story

En kort beskrivelse af en funktion set fra brugerens side: "Som kunde vil jeg kunne se mine fakturaer, så jeg ikke skal ringe og spørge." Formen tvinger alle til at tænke over hvem funktionen er til.

Backlog

Den prioriterede liste over alt der kan bygges: funktioner, rettelser og idéer. Det øverste bygges først. Det er helt normalt at den vokser hurtigere end den bliver kortere.

Agil udvikling

En arbejdsform hvor systemet bygges i små bidder som du ser og godkender løbende. Fordelen er at du kan skifte retning undervejs. Ulempen er at den endelige pris er sværere at kende på forhånd.

Sprint

En fast periode i agil udvikling, ofte en eller to uger, hvor et aftalt udsnit af backloggen bliver bygget. Bagefter ser du resultatet, og næste sprint planlægges ud fra det.

Vandfald

Den klassiske arbejdsform hvor alt specificeres først, derefter bygges og til sidst testes. Den passer når kravene er kendte og stabile, fx ved en integration til et fast dataformat.

Definition of done

En fælles aftale om hvornår en opgave er færdig, fx testet, afprøvet på staging og godkendt af dig. Uden den kan "færdig" betyde "koden er skrevet" for udvikleren og "klar til brug" for dig.

Estimat

Et kvalificeret bud på hvor lang tid en opgave tager. Det er hverken en pris eller et løfte. Jo mindre afklaret opgaven er, jo bredere bør intervallet være, så bed om et interval frem for ét tal.

Fast pris og timepris

Ved fast pris betaler du et aftalt beløb for et afgrænset omfang, og udvikleren bærer risikoen for overskridelser. Ved timepris betaler du for den tid der bliver brugt, og så bærer du risikoen.

Scope creep

Når omfanget langsomt vokser med "lige en lille ting mere". Hver ændring virker lille, men tilsammen skubber de deadline og budget. Løsningen er en fast proces hvor hvert nyt ønske får en pris og en plads i backloggen.

Kode og kvalitet

De næste ord handler om selve koden. De afgør hvor let og billigt det er at ændre systemet om et år.

Kildekode

Den tekst udvikleren skriver, og som systemet er lavet af. Sørg for at det står i aftalen at du ejer kildekoden og har adgang til den. Hos mig ejer kunden koden fra første dag.

Repository

Et kodearkiv med kildekoden og hele dens historik, typisk på GitHub eller GitLab. Bed om at det ligger på en konto du ejer eller har adgang til, så du ikke står uden kode hvis samarbejdet stopper.

Git og versionsstyring

Git er det værktøj langt de fleste udviklere bruger til versionsstyring. Det gemmer hver ændring med tidspunkt og forfatter, så en fejl kan spores tilbage til den ændring der skabte den.

Pull request og code review

En pull request er et forslag til en ændring i koden. Code review er gennemgangen, hvor en anden udvikler læser koden før den bliver lagt ind. Har projektet kun én udvikler, kan en ekstern gennemgang gøre samme nytte.

Bug

En fejl: noget der ikke virker som aftalt. Bugs findes i al software. Det vigtige er hvor hurtigt de bliver rettet, og om I har aftalt hvem der betaler for rettelsen.

Automatiserede tests

Små programmer der tjekker at systemet stadig virker hver gang koden bliver ændret. De koster lidt tid nu, men fanger fejl før dine brugere gør det.

Refaktorering

At omskrive kode så den bliver lettere at forstå og ændre, uden at den gør noget nyt. For dig ser det ud som om der intet sker, men de næste funktioner bliver billigere at bygge.

Teknisk gæld

Genveje i koden der virker nu, men gør senere ændringer dyrere. Ligesom med et lån er lidt gæld fint hvis den er et bevidst valg. Jeg har skrevet om hvad teknisk gæld koster når du venter med at gøre noget ved den.

Legacy-kode

Ældre kode som stadig driver forretningen, men er svær at ændre, fx fordi den mangler tests eller kun forstås af én person. Den skal sjældent smides ud. Tit kan den moderniseres i etaper.

Afhængigheder (pakker)

Færdige kodebiblioteker som systemet bruger, fx til betaling eller PDF-filer. De sparer tid, men skal opdateres løbende, fordi gamle versioner kan have sikkerhedshuller.

Dokumentation

Beskrivelser af hvordan systemet er bygget, sat op og drevet, så en anden udvikler kan overtage. En README (introduktionsfil i kodearkivet), en oversigt over integrationer og en vejledning til udrulning rækker langt.

Drift og hosting

Når systemet er bygget, skal det køre et sted og holdes kørende. Disse ord dukker op i hostingtilbud og serviceaftaler.

Hosting

Den tjeneste der stiller en server til rådighed og holder dit system online mod en månedlig betaling. Spørg hvor serveren står, særligt hvis systemet indeholder persondata.

Server og cloud

En server er en computer der kører dit system og kan nås via internettet. Cloud betyder at du lejer serverkraft hos en stor udbyder som AWS eller Microsoft Azure, så kapaciteten kan skrues op og ned.

Domæne og DNS

Domænet er adressen, fx simonij.com. DNS er internettets telefonbog, der oversætter domænet til den rigtige server. Domænet bør være registreret i dit navn og ikke i udviklerens.

SSL-certifikat

Det der giver https og en hængelås i browseren. Forbindelsen mellem bruger og server bliver krypteret, så ingen kan læse med. Et certifikat kan fås gratis, fx via Let's Encrypt.

Lokal, staging og produktion

De tre miljøer et system typisk kører i: udviklerens egen computer, en testkopi og det rigtige system dine brugere bruger. Ændringer bør gå gennem staging, så du kan teste før de når produktion.

Deploy

At udgive en ny version af koden på serveren, også kaldet udrulning. En god opsætning gør det til et klik eller en automatisk proces, så det ikke afhænger af én persons hukommelse.

CI/CD

Continuous integration og continuous delivery: en automatisk proces der kører testene ved hver ændring og udgiver den nye version hvis alt er i orden. Det giver færre fejl ved udgivelser.

Backup

En sikkerhedskopi af data og filer, gemt et andet sted end selve systemet. En backup er kun noget værd hvis den er testet. Spørg hvornår nogen sidst prøvede at gendanne den.

Overvågning

Automatisk kontrol af om systemet er oppe og fungerer, med besked til udvikleren når noget går galt. Formålet er at problemet bliver opdaget før dine kunder ringer.

Oppetid og SLA

Oppetid er den andel af tiden systemet er tilgængeligt, angivet i procent. En SLA (service level agreement) er aftalen om oppetid og svartider. Højere oppetid koster mere, så aftal det niveau du faktisk har brug for.

Cache og CDN

Cache er gemte kopier af data eller sider, så de ikke skal beregnes forfra hver gang. Et CDN (content delivery network) leverer billeder og filer fra en server tæt på brugeren. Begge dele gør systemet hurtigere.

Sikkerhed, data og jura

De sidste ord handler om ansvar. Flere af dem har juridiske konsekvenser, så tal med en rådgiver hvis du er i tvivl om dine pligter.

GDPR

EU's databeskyttelsesforordning, der regulerer hvordan persondata må indsamles, opbevares og bruges. Gemmer dit system navne, mailadresser eller andre oplysninger om personer, gælder reglerne.

Databehandleraftale

En aftale med en leverandør der behandler persondata på dine vegne, fx dit hostingfirma. Ifølge Datatilsynets vejledning om dataansvarlige og databehandlere er det dit ansvar som dataansvarlig at aftalen bliver lavet.

Kryptering

At gøre data ulæselige for alle uden den rigtige nøgle, både under transporten og på serveren. Adgangskoder bør gemmes som en hash, en envejsomregning, så heller ikke udvikleren kan læse dem.

To-faktor-login (2FA)

Login der kræver både noget du ved, som en adgangskode, og noget du har, fx en kode fra en app på telefonen. Det gør det langt sværere at overtage en konto med en stjålet adgangskode.

Roller og rettigheder

Regler for hvem der må se og gøre hvad, fx at en medarbejder kan se ordrer, mens kun en administrator kan ændre priser. Det er nemmere at bygge ind fra start end at tilføje bagefter.

Sårbarhed

En svaghed i koden eller opsætningen som en angriber kan udnytte. OWASP udgiver en liste over de mest kritiske sikkerhedsrisici i webapps, og den er et godt udgangspunkt for spørgsmål til din udvikler.

Penetrationstest

En test hvor en sikkerhedsspecialist med din tilladelse prøver at bryde ind i systemet for at finde svagheder. Den er relevant når systemet håndterer følsomme data, penge eller mange brugere.

Logning

Systemets automatiske dagbog over fejl, loginforsøg og vigtige handlinger. Logs er det første en udvikler kigger i når noget går galt. De kan indeholde persondata og skal derfor slettes efter en periode.

Vendor lock-in

Når det er svært eller dyrt at skifte leverandør, fordi systemet bygger på en lukket platform eller kun én person forstår koden. Du mindsker risikoen ved selv at eje koden, domænet og hostingkontoen.

Webtilgængelighed (WCAG)

At systemet kan bruges af alle, også med skærmlæser eller kun tastatur. Standarden hedder WCAG og udgives af W3C, og man sigter typisk efter niveau AA. EU's tilgængelighedsdirektiv (European Accessibility Act) stiller krav til blandt andet e-handel og banktjenester.

Næste skridt: brug ordene i dit næste møde

Du behøver ikke lære ordbogen udenad. Tag de seks begreber fra tabellen øverst med til dit næste møde med en udvikler, og spørg ind til dem. Svarene fortæller dig meget om hvordan vedkommende arbejder.

Tre ærlige råd:

• Skal du kun have en enkel hjemmeside, er halvdelen af ordene her ligegyldige for dig. Så er Wix eller Squarespace ofte billigere og hurtigere end at hyre en udvikler som mig.
• Bruger en udvikler fagord uden at forklare dem, eller bliver vedkommende utålmodig når du spørger, så tag det som et forvarsel om samarbejdet.
• Skriv de begreber I bliver enige om ind i aftalen, især hvad "færdig" betyder.

Vil du se hvilke opgaver jeg hjælper med, fra hjemmesider til webapps og SaaS, så kig på oversigten over mine ydelser. Du taler direkte med mig, får et forprojekt til fast pris før større opgaver og ejer koden fra første dag.

Ofte stillede spørgsmål

Hvorfor bruger udviklere så mange engelske ord?+

Fordi de fleste værktøjer, dokumentation og fagmiljøer i softwareudvikling er engelsksprogede. Mange ord som deploy, backlog og pull request har ingen dansk afløser som alle bruger. Det er helt rimeligt at bede om en forklaring på dansk, og en udvikler der kender sit fag, kan give den uden at tøve.

Skal jeg kunne kode for at styre et udviklingsprojekt?+

Nej. Din vigtigste opgave er at beskrive problemet, prioritere hvad der er vigtigst, og teste det der bliver bygget med dine brugeres øjne. Det hjælper at kende de mest brugte begreber, så du kan stille de rigtige spørgsmål, men den tekniske vurdering er udviklerens ansvar.

Hvad betyder det når et system er skalerbart?+

At systemet kan klare flere brugere eller mere data uden at skulle bygges om, fx ved at give serveren mere kraft eller fordele arbejdet på flere servere. For de fleste nye projekter er det vigtigere at koden er nem at ændre end at den kan klare millioner af brugere fra dag ét.

Hvad er forskellen på en udvikler og en programmør?+

I praksis bliver ordene ofte brugt om det samme. Programmør lægger vægt på at skrive kode, mens udvikler tit dækker mere: at forstå problemet, foreslå en løsning, bygge den og holde den kørende. Spørg hellere hvilke dele af projektet personen selv tager ansvar for end at gå op i titlen.