Det problem, vi alle kender

Forestil dig det. En udvikler leverer en ny funktion, der kører fint teknisk set. Men den passer ikke til, hvad produktfolket havde i tankerne. Eller værre: Tre måneder senere opdager du, at dine microservices tolker det samme datfelt på totalt forskellige måder.

Det handler ikke om dårlig kode. Det er manglende kommunikation.

De gamle workflows hviler på spredt dokumentation, Slack-threads og viden, der sidder i folks hoveder. Vi har prøvet med skarpere code reviews, bedre commit-messages og fede README-filer. Men sandheden er hård: Kode er ikke en specifikation. Kode er en realisering. Det er to forskellige ting.

Hvad er specification-driven development?

SDD vender det traditionelle på hovedet. I stedet for at kode først og krydse fingre for, at det matcher intentionen, definerer du adfærden på forhånd – uden at blande implementationsdetaljer ind.

Tænk på det som at bygge et hus. Du smider ikke bare materialer i hånden på håndværkeren og siger "lav noget". Du giver blueprints med mål, materialer og hvordan systemerne hænger sammen. Håndværkeren kan vælge sin metode, men resultatet er forudsigeligt.

I software kan en spec beskrive:

• API-endpoints: request/response-schemas, fejltilstande, rate limiting
• Tilstandsskift: Gyldige overgange, side effects, rollback
• Integrationer: Hvordan services snakker sammen, dataformater
• Kanter: Grænseværdier, null-håndtering, concurrency

Det fedeste? Specs er testbare og delbare. QA kan teste mod dem. Docs genereres automatisk. Nye udviklere forstår systemet uden at pløje gennem tusindvis af kodlinjer.

Hvorfor har teams brug for det?

Problemer i ét repo

Selv i et monorepo kan pakker glide fra hinanden i deres antagelser. Specs skaber én sandhedskilde, der stopper den stille uoverensstemmelse.

Kaos i monorepo

Med dusinvis af services i ét repo bliver specs uundværlige. De dokumenterer kontrakter mellem services, gør refactoring sikrere og onboarding hurtigere.

Mareridt med flere repos

Har du microservices spredt over flere repos? Specs er din redning. De er det skriftlige aftale om interaktion – versionstyret og reviewbart som kode.

Fordele for udviklerne

Når du går over til SDD, sker der noget med hverdagen:

Code reviews bliver skarpe. Ingen diskussion om "skal det her gøre X?" – det står i spec'en. Fokus på kvalitet, performance og vedligeholdelse.

Onboarding går lynhurtigt. Nye folk læser spec'en, kender kontrakten og koder trygt. Ingen "venter det her endpoint et array eller objekt?"

Test bliver smarte. Specs definerer præcis, hvad der skal testes. Ingen gætteri.

Refactoring føles trygt. Så længe ny kode opfylder spec'en, kan du omskrive indersiden uden frygt for skjulte afhængigheder.

Hvordan gør du det teknisk?

Moderne SDD-værktøjer (som SpecD på GitHub) tilbyder typisk:

• Spec-format der er læsbart for mennesker og maskiner
• Validering der tjekker kode mod specs
• Doc-generering der holder dokumentation frisk
• Støtte til flere repos i distribuerede setups

Mange teams vælger kendte standarder: OpenAPI til API-kontrakter, JSON Schema til data, eller property-based testing til adfærd.

Vigtigst: Vælg noget, I vedligeholder. En forældet spec er værre end ingen.

Hvornår skal du starte?

Gå efter SDD, hvis:

• Dit team er over 3 personer og krangler om funktionalitet
• Du har API'er, flere services bruger
• Du skalerer fra monolith til microservices
• Du vil splitte arbejde mellem teams
• Du er træt af integrationsoverraskelser

Spring det over, hvis:

• Du bygger solo uden afhængigheder
• Alt koder i ét hoved og ændres sjældent
• I kommunikerer perfekt (lykkelige jer!)

Sådan kommer du i gang

Her er den praktiske plan:

1. Start med API-grænser. Specs skinner, hvor systemer mødes. Formaliser én API-kontrakt.

2. Vælg format. OpenAPI, AsyncAPI eller property-tests – hvad passer til jeres stack?

3. Gør det udførligt. Brug linting, runtime-checks eller automatiserede tests.

4. Integrér i reviews. Spec-review bliver lige så obligatorisk som code review.

5. Mål gevinsten. Tæl bugs fanget, onboarding-tid, refactoring-sikkerhed.

Det store billede

SDD er ikke nyt – arkitekter har brugt specs i årevis. Nyheden er at bruge det i distribuerede systemer, hvor misforståelser koster kæmpe.

Jo større dit system, jo dyrere bliver tvetydighed. En uklar spec i en monolith giver ét problem. Over ti microservices? Ti fortolkninger.

Med eksplicitte, testbare specs i centrum får du færre bugs. Du bygger klarhed ind i kulturen. Koden bliver robust mod folk skifter. Teams kan arbejde parallelt, fordi alle er enige om kontrakten – ikke bare koden.

Det er den ægte gevinst.

Klar til at opgradere din dev-flow? Uanset om du definerer API-kontrakter i distribuerede systemer eller service-grænser i monorepo'et, adskiller klare specs kaos fra orden. Kombinér med solid hosting, og du har skalérbar fundament.

Hos NameOcean ved vi, at stærke systemer kræver solide baser – uanset om det er pålidelig DNS eller hosting, der vokser med din arkitektur. Dine specs siger, hvad koden skal gøre. Den rigtige platform sikrer, den gør det stabilt.