39Teknologi

Loven om utætte abstraktioner

Alle ikke-trivielle abstraktioner lækker: før eller siden må man forstå lagene under for at fejlsøge eller bruge dem korrekt.

Kort fortalt

Loven om utætte abstraktioner siger, at alle ikke-trivielle abstraktioner lækker. De skjuler detaljer det meste af tiden — indtil de ikke gør, og man må kende det underliggende system.

Hvad betyder princippet?

Joel Spolsky beskrev loven i 2002. Abstraktioner (ORM’er, cloud-API’er, filsystemer, netværksprotokoller) gør arbejde lettere, men deres begrænsninger og fejltilstande afspejler stadig den virkelighed, de pakker ind.

Konsekvensen er dobbelt: abstraktioner er værdifulde, men de fjerner ikke behovet for forståelse. De udskyder det.

Når abstraktionen fejler, betaler du prisen for alt det, den gemte.

Et konkret eksempel

Et ORM lader dig arbejde med objekter i stedet for SQL. Det virker, indtil en N+1-forespørgsel gør siden langsom. For at rette den må udvikleren forstå både ORM’ets adfærd og den underliggende database.

“Serverless” skjuler serveradministration, indtil cold starts, timeouts eller concurrency-grænser kræver viden om den konkrete platform.

Hvornår er princippet nyttigt?

  • Når man vælger frameworks og platforme.
  • Når fejl kun kan forstås ét lag dybere.
  • Når man onboarde’r folk til “magiske” værktøjer.
  • Når man vurderer, hvor meget kompleksitet en abstraktion faktisk fjerner.

Begrænsninger og kritik

Loven er en aforisme, ikke en formaliseret lov. Den betyder ikke, at abstraktioner er dårlige — kun at de har omkostninger. Gode abstraktioner lækker sjældnere eller mere forudsigeligt.

Brug den til at budgettere læring og fejlfinding — ikke til at undgå alle lag.

Kilder

  1. Joel Spolsky, “The Law of Leaky Abstractions” (2002).
  2. Bemærkning: Teksten er en indflydelsesrig essayistisk formulering inden for software engineering.
  • 34KISS-princippetHold løsninger så enkle som muligt — kompleksitet bør være begrundet, ikke standard.
  • 50Postels lovVær konservativ i det, du sender, og liberal i det, du accepterer — for mere robust kommunikation mellem systemer.
  • 54SOLID-principperneFem objektorienterede designprincipper, der sigter mod mere forståelig, fleksibel og vedligeholdelig software.
  • 14DRY-princippetDon't Repeat Yourself: undgå at den samme viden findes i flere, uafhængige kopier, der kan komme ud af sync.