Fällan med designmönster

Låt oss vara ärliga: om du har jobbat med mjukvaruutveckling i mer än ett par år har du troligtvis suttit med på en arkitektgranskning där någon dragit fram en mönsterkatalog som om det vore en restaurangmeny. "Vi skulle kunna använda en Factory här. Kanske Strategy-mönster där. Har du funderat på CQRS?"

Det här är ingen arkitektur. Det är mönsterpassning förklädd till ingenjörskonst.

En tanke som ofta dyker upp i utvecklarcommunityn fångar detta perfekt: bra mjukvaruarkitektur växer fram genom att modellera problemet självt, snarare än att försöka klämma in problemet i en förutbestämd uppsättning mönster. De bästa utvecklarna lär sig sina verktyg, förstår sina material, och följer sedan sin vision – istället för att greppa efter stansade mallar som döljer den uppenbara lösningen som ligger rakt framför dem.

Varför finns det webbutvecklingsresurser överallt, men systemprogrammering är svårt att hitta?

Om du vill lära dig om mikrotjänster, containerorkestrering eller distribuerade system i webbsammanhang – gratulerar, du drunknar i resurser. Men vad händer om du bygger en kompilator, ett inbyggt system, en spelmotor eller en databas?

Landskapet förändras dramatiskt.

Det mesta av innehållet om "mjukvaruarkitektur" idag fokuserar på webbskaliga applikationers bekymmer: horisontell skalning, tjänstidentifiering, eventuell konsistens och de organisatoriska utmaningarna som följer med stora utvecklarteam. Det här är legitima problem, men de är inte universella problem.

För systemprogrammerare och icke-webbutvecklare skiftar vokabuläret. Du tänker på:

• Minneslayout och åtkomstmönster
• Latensgarantier och realtidsbegränsningar
• Resursbegränsade miljöer
• Formell verifiering när korrekthet är kritisk
• Att bygga för decennier av underhåll, inte bara nästa sprint

Utmaningen är att bra resurser för den här världen är spridda, ofta akademiska, och sällan definierar sig själva som "arkitektur" – även när de absolut är det.

Vad som faktiskt hjälper: Tankemodeller istället för mönster

Istället för ännu en mönsterkatalog, här är de tankeramverk som visat sig mest värdefulla för att bygga robusta system, oavsett om du skriver inbäddad C eller enterprise Java:

1. Begränsningar först

Varje system existerar inom begränsningar: budget, tid, teamstorlek, prestandakrav, regulatorisk miljö. Arkitekturen som växer fram från att djupt förstå dina begränsningar kommer alltid överträffa den "korrekta" arkitekturen som ignorerar dem.

2. Dataflödet som grund

Innan du börjar tänka på klasser, moduler eller tjänster – förstå hur data kommer in i ditt system, transformerar och lämnar. Arkitektur blir ofta uppenbar när du kartlägger detta tydligt. Underliga abstraktioner faller bort; nödvändiga blir klara.

3. Ägandeskap av beroenden

Vem äger den här datan? Vem kan modifiera det här tillståndet? Tydliga svar på de här frågorna förhindrar de flesta arkitektoniska problem. Förvirringen kring ägandeskap – särskilt dataägandeskap – är var de flesta system börjar ruttna.

4. Kostnaden för indirektion

Varje abstraktion har en kostnad. Varje lager av indirektion gör felsökning svårare och prestanda svårare att reasona om. Frågan är inte "ska jag abstrahera det här?" utan "vad köper jag med den här abstraktionen, och är det värt priset?"

5. Lokalitet beteende

Kod som är lätt att förstå isolerat, som inte kräver att du håller tre filer i huvudet samtidigt, är kod som kommer att överleva de närmaste fem årens underhåll. Arkitektur som skapar kognitiv belastning kommer så småningom att förenklas – ofta av någon som inte förstår varför det byggdes så där.

Rekommenderade resurser (den icke-webb sorten)

Om du vill fördjupa ditt arkitekturtänkande utan att falla ner i webbskalans mönsterkaninhål, överväg:

• "A Philosophy of Software Design" av John Ousterhout — Detta förblir ett av de tydligaste tänkandena kring komplexitetshantering i mjukvarusystem. Det är språkagnostiskt och djupt praktiskt.

• Akademiska artiklar om operativsystem och distribuerade system, särskilt de som föregår mikrotjänst-eran. Artiklar om filsystemsdesign innehåller exempelvis arkitektonisk visdom tillämpbar långt bortom filsystem.

• Att läsa källkoden för väldesignade system — Det låter uppenbart, men de flesta utvecklare gör det inte systematiskt. Att förstå hur databaser, kompilatorer och väldesignade open source-projekt löser svåra problem lär dig mer än någon mönsterbok.

Konsten bakom vetenskapen

Här är den obekväma sanningen: mjukvaruarkitektur är mer konst än vetenskap, och det kommer inte att förändras.

Vi kan prata om principer och heuristik. Vi kan mäta koppling och sammanhang. Vi kan skapa modeller och diagram. Men i slutändan speglar arkitektur omdömet hos de människor som bygger systemet – deras förmåga att se problemet tydligt, deras erfarenhet av vad som tenderar att gå fel, och deras skicklighet i att göra avvägningar som tjänar verkliga behov snarare än teoretiska ideal.

De utvecklare som bygger de bästa systemen delar ofta en gemensam egenskap: de är djupt nyfikna på problemdomänen, inte bara teknologin. De frågar "varför är det här svårt?" innan de frågar "vilket mönster ska jag använda?"

Börja där. Förstå ditt problem djupt. Låt lösningen växa fram. Och när någon försöker sälja dig ett mönster som arkitektur, fråga dem vilket problem det löser – och om det problemet faktiskt existerar i ditt system.