Softwareingeniør, der bygger stabile, forretningskritiske systemer.

Ukendt er også en værdi

Problemet

Når et tal ikke kan udledes af kilderne, returnerer koden ofte et plausibelt tal alligevel. Det havner så i grafer og rapporter, uden at nogen kan se, at det var et gæt.

Hvornår det er relevant

Når man bygger rapporter eller dashboards på ufuldstændige data, fx en lønsammenligning, hvor én kilde inkluderer pension, mens en anden ikke siger noget om det.

Det viser demoen

Åbn maybe.ts og salary.ts. En beregning returnerer enten en kendt værdi eller unknown med en obligatorisk begrundelse, og TypeScript lader ikke kalderen bruge tallet, før det ukendte tilfælde er håndteret. Se på change(): den afviser af to forskellige grunde, manglende oplysning om pension og forskelligt ugentligt timetal.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Ukendt er også en værdi

Problemet

Når et tal ikke kan udledes af kilderne, returnerer koden ofte et plausibelt tal alligevel. Det havner så i grafer og rapporter, uden at nogen kan se, at det var et gæt.

Hvornår det er relevant

Når man bygger rapporter eller dashboards på ufuldstændige data, fx en lønsammenligning, hvor én kilde inkluderer pension, mens en anden ikke siger noget om det.

Det viser demoen

Åbn maybe.ts og salary.ts. En beregning returnerer enten en kendt værdi eller unknown med en obligatorisk begrundelse, og TypeScript lader ikke kalderen bruge tallet, før det ukendte tilfælde er håndteret. Se på change(): den afviser af to forskellige grunde, manglende oplysning om pension og forskelligt ugentligt timetal.

Læsemodel adskilt fra skrivesiden

Problemet

Når de samme entiteter skal bære både forretningsregler og skærmbilleder, ender en oversigtsside med at hente flere aggregater og bygge rækkerne i en løkke, og en ændring af skærmen kan ramme reglerne.

Hvornår det er relevant

En Spring-applikation, hvor ét skærmbillede skal bruge en flad, samlet visning (her en kontooversigt), mens overførsler skal følge faste regler inden for én transaktion.

Det viser demoen

Sammenlign de to filer. AccountSummaryQuery.java returnerer en simpel record fra én SQL-forespørgsel uden entiteter. TransferService.java håndhæver reglerne for overførsler og kender ikke til skærmen. Bemærk, at konti låses i id-rækkefølge for at undgå deadlocks, og at der hverken er en ekstra database eller en event bus.

Læsemodel adskilt fra skrivesiden

Problemet

Når de samme entiteter skal bære både forretningsregler og skærmbilleder, ender en oversigtsside med at hente flere aggregater og bygge rækkerne i en løkke, og en ændring af skærmen kan ramme reglerne.

Hvornår det er relevant

En Spring-applikation, hvor ét skærmbillede skal bruge en flad, samlet visning (her en kontooversigt), mens overførsler skal følge faste regler inden for én transaktion.

Det viser demoen

Sammenlign de to filer. AccountSummaryQuery.java returnerer en simpel record fra én SQL-forespørgsel uden entiteter. TransferService.java håndhæver reglerne for overførsler og kender ikke til skærmen. Bemærk, at konti låses i id-rækkefølge for at undgå deadlocks, og at der hverken er en ekstra database eller en event bus.

Result frem for exception

Problemet

Hvis "bilen er allerede booket" og "databasen er nede" kastes som samme slags exception, skriver hver kalder den samme catch-blok, og de to tilfælde bliver blandet sammen.

Hvornår det er relevant

Et team, der bygger et web-API i .NET og har brug for ærlige statuskoder: forventede forretningsfejl håndteres af kalderen, infrastrukturfejl samles ét centralt sted.

Det viser demoen

I BookingEndpoint.cs kommer en booking tilbage som et Result. En dobbeltbooking giver 409 og omvendte datoer 400, mens en tabt forbindelse stadig kaster en exception og ender som 500. Handleren har slet ingen try/catch.

Penge som værdiobjekt

Problemet

Kommatal taber brøkdele af en krone, intet forhindrer, at kroner lægges sammen med euro, og når et beløb deles i tre, forsvinder en enhed, uden at nogen opdager det.

Hvornår det er relevant

Ethvert system med priser, fakturaer eller udbetalinger, hvor beløb skal gå præcist op, og valutaer aldrig må blandes.

Det viser demoen

Money.php gemmer beløb som hele mindsteenheder (øre, cent) med valutaen inde i objektet. Lægger man to forskellige valutaer sammen, kastes en fejl, og allocate() deler 100 i 34, 33 og 33, så delene altid summerer til det hele. Hver operation returnerer et nyt objekt.

Læsemodel adskilt fra skrivesiden

Problemet

Når de samme entiteter skal bære både forretningsregler og skærmbilleder, ender en oversigtsside med at hente flere aggregater og bygge rækkerne i en løkke, og en ændring af skærmen kan ramme reglerne.

Hvornår det er relevant

En Spring-applikation, hvor ét skærmbillede skal bruge en flad, samlet visning (her en kontooversigt), mens overførsler skal følge faste regler inden for én transaktion.

Det viser demoen

Sammenlign de to filer. AccountSummaryQuery.java returnerer en simpel record fra én SQL-forespørgsel uden entiteter. TransferService.java håndhæver reglerne for overførsler og kender ikke til skærmen. Bemærk, at konti låses i id-rækkefølge for at undgå deadlocks, og at der hverken er en ekstra database eller en event bus.

En ratchet-gate

Problemet

Slår man en lint-regel til i en kodebase, der allerede bryder den tusindvis af gange, står valget mellem at blokere alle builds eller nøjes med advarsler, som ingen reagerer på.

Hvornår det er relevant

Et team, der indfører en ny regel i en eksisterende kodebase og vil have, at ny kode følger den fra første dag, mens den gamle kode bliver bedre over tid.

Det viser demoen

Invoke-RatchetGate.ps1 læser en ESLint-rapport i JSON, tæller overtrædelser pr. regel mod en baseline i repositoriet og fejler kun, når et tal stiger. Baselinen sænkes kun automatisk; at hæve den kræver et commit, som en reviewer kan se.