Glem patterns – det her betyder noget i din softwarearkitektur

Fælden med patterns

Lad os være ærlige: Har du arbejdet med softwareudvikling i mere end et par år, har du sikkert siddet i et arkitekturreview, hvor nogen hev et pattern-katalog frem som en tjener med en menukort. "Vi kunne bruge en Factory her. Måske en Strategy pattern der. Har du overvejet CQRS?"

Det her er ikke arkitektur. Det er mønstergenkendelse forklædt som ingeniørarbejde.

En tanke der bliver ved med at dukke op i udviklermiljøerne rammer plet: God softwarearkitektur opstår ved at modellere selve problemet, frem for at forsøge at presse problemet ind i en forudbestemt samling af patterns. De bedste udviklere lærer hvordan de bruger deres værktøjer, forstår deres materialer, og følger derefter deres vision — i stedet for at gribe fat i skabeloner, der skjuler den oplagte løsning der sidder lige foran dem.

Hvorfor er der webudviklingsressourcer overalt, men systemsprogrammering-arkitektur er svær at finde?

Vil du lære om microservices, containerorkestrering eller distribuerede systemer i webkonteksten, tillykke — du drukner i ressourcer. Men hvad hvis du bygger en compiler, et indlejret system, en spilmotor eller en database?

Landskabet ændrer sig dramatisk.

Det meste af "softwarearkitektur"-indhold fokuserer i dag på bekymringer fra web-skala-applikationer: horizontal skalering, service discovery, eventual consistency og de organisatoriske udfordringer der følger med store ingeniørteams. Det er legitime problemer, men de er ikke universelle problemer.

For systemsprogrammører og ikke-web-udviklere skifter ordforrådet. Du tænker på:

• Hukommelseslayout og adgangsmønstre
• Latensgarantier og realtidskrav
• Ressourcebegrænsede miljøer
• Formel verifikation når korrekthed er kritisk
• Bygget til årtiers vedligeholdelse, ikke bare den næste sprint

Udfordringen er at gode ressourcer til denne verden er spredt, ofte akademisk, og sjældent placerer sig selv som "arkitektur" — selv når de absolut er det.

Hvad der faktisk hjælper: Mentale modeller frem for patterns

I stedet for endnu et pattern-katalog, her er de mentale rammer der har vist sig mest værdifulde til at bygge robuste systemer, uanset om du skriver indlejret C eller enterprise Java:

1. Begrænsninger først

Ethvert system eksisterer inden for begrænsninger: budget, tid, teamstørrelse, performancekrav, regulatorisk miljø. Arkitekturen der opstår fra dyb forståelse af dine begrænsninger vil altid overgå den "korrekte" arkitektur der ignorerer dem.

2. Dataflow som fundamentet

Før du tænker på klasser, moduler eller services, forstå hvordan data kommer ind i dit system, transformerer, og forlader det. Arkitektur bliver ofte oplagt når du kortlægger dette klart. Underlige abstraktioner forsvinder; nødvendige bliver tydelige.

3. Ejerskab af afhængigheder

Hvem ejer de her data? Hvem kan ændre den her tilstand? Klare svar på de spørgsmål forebygger de fleste arkitekturproblemer. Forvirring omkring ejerskab — især dataejerskab — er der hvor de fleste systemer begynder at rådne.

4. Omkostningen ved indirektion

Enhver abstraktion har en pris. Hvert lag af indirektion gør debugging sværere og performance sværere at reason om. Spørgsmålet er ikke "skal jeg abstrahere det her?" men "hvad køber jeg med den her abstraktion, og er det prisen værd?"

5. Lokalitet af adfærd

Kode der er let at forstå i isolation, der ikke kræver at du holder tre filer i hovedet på én gang, er kode der vil overleve de næste fem års vedligeholdelse. Arkitektur der skaber kognitiv belastning vil til sidst blive forenklet — ofte af nogen der ikke forstår hvorfor det blev bygget sådan.

Anbefalede ressourcer (den ikke-web type)

Leder du efter at uddybe din arkitekturtænkning uden at falde ned i web-skala pattern-kaninhullet, overvej:

• "A Philosophy of Software Design" af John Ousterhout — Det her er stadig en af de klareste tanker om kompleksitetshåndtering i softwaresystemer. Det er sprog-agnostisk og dybt praktisk.

• Papers om operativsystemer og distribuerede systemer fra den akademiske litteratur, særligt dem der prædaterer microservices-æraen. Papers om filsystemsdesign indeholder for eksempel arkitekturvisdom der gælder langt ud over filsystemer.

• At læse kildekoden af veldesignede systemer — Det lyder indlysende, men de fleste udviklere gør det ikke systematisk. At forstå hvordan databaser, compilere og vel-engineerede open source-projekter løser svære problemer vil lære dig mere end nogen pattern-bog.

Kunsten bag videnskaben

Her er den ubehagelige sandhed: Softwarearkitektur er mere kunst end videnskab, og det ændrer sig ikke.

Vi kan tale om principper og heuristikker. Vi kan måle kobling og sammenhængskraft. Vi kan skabe modeller og diagrammer. Men i sidste ende afspejler arkitektur dommefærdigheden hos de mennesker der bygger systemet — deres evne til at se problemet klart, deres erfaring med hvad der plejer at gå galt, og deres dygtighed til at foretage afvejninger der tjener virkelige behov frem for teoretiske idealer.

De udviklere der bygger de bedste systemer deler en fælles egenskab: De er dybt nysgerrige på problemdomænet, ikke bare teknologien. De spørger "hvorfor er det her svært?" før de spørger "hvilket pattern skal jeg bruge?"

Start der. Forstå dit problem dybt. Lad løsningen opstå. Og når nogen prøver at sælge dig et pattern som arkitektur, spørg dem hvilket problem det løser — og om det problem faktisk eksisterer i dit system.