Standards für Softwareentwicklung & Systemdesign
Ein rigoroser, praxiserprobter Betriebsleitfaden für Softwareentwicklungsexzellenz, Systemarchitektur, Low-Level-Design und verteilte Systeme.
1. Grundlegende Betriebsprinzipien
- Kompromisse statt Dogma: Es gibt keine universellen "Best Practices", nur Kompromisse. Jede architektonische Entscheidung erkauft eine Reihe von Vorteilen durch die Zahlung eines spezifischen Preises (Latenz, Konsistenz, Betriebskomplexität oder kognitive Belastung). Geben Sie immer an, was geopfert wird.
- Reversibilität zuerst: Priorisieren Sie Zwei-Wege-Entscheidungen (umkehrbar) vor Einbahnstraßen-Entscheidungen (unumkehrbar). Vermeiden Sie vorzeitige Kopplung an bestimmte Anbieter, Frameworks oder verteilte Topologien.
- Keine Architektur-Astronautik: Jede Abstraktion, Schnittstelle und Schicht muss ihr Gewicht anhand konkreter bestehender Anforderungen rechtfertigen, nicht anhand spekulativer zukünftiger Bedürfnisse (YAGNI).
- Evidenzbasierte Entscheidungen: Treffen Sie Entscheidungen auf der Grundlage konkreter Profile, Messungen, Abfragepläne (
EXPLAIN ANALYZE) und Kapazitätsgrenzen, nicht auf Annahmen. - Fail-Fast & explizite Grenzen: Grenzen zwischen Subsystemen, Domänen oder Netzwerk-Hops müssen explizite, stark typisierte Verträge, Validierung, Timeouts, Circuit Breaker und Idempotenzgarantien haben.
2. High-Level-Design (HLD) & Architektur-Workflow
Wenn Sie aufgefordert werden, ein System zu entwerfen, eine Architektur zu bewerten oder ein größeres Subsystem umzustrukturieren, führen Sie dieses 6-Schritte-Framework aus:
flowchart TD
Step1["1. Anforderungen & Umfang klären<br>(Funktional, Nicht-funktional, Latenz, Verfügbarkeit, Konsistenz)"]
Step2["2. Kapazität & Skalenschätzung<br>(DAU, QPS, Durchsatz, Netzwerkbandbreite, Speicher, Cache-RAM)"]
Step3["3. High-Level-Architektur (C4 L1/L2)<br>(Service-Grenzen, Speicherauswahl, Ingress, Caching)"]
Step4["4. Datenmodell & Schnittstellenverträge<br>(Entitäten, Schemata, Primärschlüssel, Indizes, REST/gRPC-APIs)"]
Step5["5. Deep Dives & Engpass-Isolierung<br>(Replikation, Sharding, Parallelität, Caching-Pathologien, Hotspots)"]
Step6["6. Resilienz & SRE-Strategie<br>(SLOs, Circuit Breaker, Retries mit Jitter, Idempotenz, DLQs)"]
Step1 --> Step2 --> Step3 --> Step4 --> Step5 --> Step6
Detaillierte HLD-Referenz
Für Theoreme verteilter Systeme (CAP, PACELC), Konsistenzhierarchien, Konsens (Raft/Paxos), Sharding, Replikation, das Saga-Muster und das Transactional Outbox-Muster konsultieren Sie: 👉 High-Level System Design & Distributed Systems Reference
3. Low-Level-Design (LLD) & Clean Code Standards
Halten Sie sich beim Schreiben, Überprüfen oder Umstrukturieren von Code an diese Standards:
3.1 Die SOLID-Regeln
- SRP (Single Responsibility): Ein Modul hat einen Akteur/Stakeholder, dem es Rechenschaft schuldet. Extrahieren Sie Persistenz, HTTP-Serialisierung und Geschäftslogik in separate Belange.
- OCP (Open/Closed): Bevorzugen Sie Polymorphie, Strategie- oder Besuchermuster gegenüber ausufernden
switch/if-elseTyp-Dispatch-Anweisungen. - LSP (Liskov Substitution): Subtypen müssen alle Verhaltensinvarianten der Eltern erfüllen. Das Überschreiben von Methoden, um
NotImplementedExceptionzu werfen, verletzt LSP. - ISP (Interface Segregation): Bevorzugen Sie kleine, kundenspezifische Rollenschnittstellen gegenüber breiten "Gott-Schnittstellen".
- DIP (Dependency Inversion): Kern-Geschäftsregeln hängen nur von Abstraktionen (Ports) ab, niemals direkt von externen Datenbankbibliotheken, UI-Frameworks oder Netzwerktreibern.
3.2 Modulare Kapselung (Parnas & Connascence)
- Modul-Geheimnisse: Ein Modul muss sein primäres Geheimnis (interne Algorithmen/Datenstrukturen) und sein sekundäres Geheimnis (externe Umgebungen/Dateiformate) vollständig verbergen.
- Connascence: Minimieren Sie dynamische Connascence (Ausführungsreihenfolge, Timing, Werteinschränkungen) und reduzieren Sie die Kopplung auf statische Namens-/Typ-Vereinbarungen.
Detaillierte LLD-Referenz
Für Feldhandbücher zu Entwurfsmustern der Gang of Four (GoF), taktische Bausteine des Domain-Driven Design (DDD) (Entitäten, Value Objects, Aggregate, Domain Events) und Refactoring-Techniken konsultieren Sie: 👉 Low-Level Design & Clean Code Reference
4. API & Datenpersistenzstandards
- RESTful APIs:
- Halten Sie sich strikt an die HTTP-Methodensemantik (
GETist sicher & idempotent;PUT/DELETEsind idempotent;POSTerstellt). - Verwenden Sie RFC 7807 (Problem Details) für strukturierte Fehlerantworten.
- Verwenden Sie für Sammlungen mit hohem Volumen Keyset/Cursor-Paginierung anstelle von Offset/Limit-Paginierung.
- Halten Sie sich strikt an die HTTP-Methodensemantik (
- Datenbank-Indizierung (Die E-R-S-Regel):
- Reihenfolge der Spalten in zusammengesetzten Indizes: [Gleichheitsspalten] $\to$ [Bereichsspalten] $\to$ [Sortierspalten].
- Verwenden Sie Abdeckende Indizes (Index-Only Scans) und Partielle Indizes, um Festplatten-Seitenzugriffe für heiße Abfragen zu eliminieren.
- Überprüfen Sie Abfragen immer mit
EXPLAIN QUERY PLANoderEXPLAIN ANALYZE.
- Asynchrone Nachrichtenübermittlung & Ereignisse:
- Garantieren Sie effektiv-Einmal-Verarbeitung durch Kombination von Mindestens-Einmal-Broker-Zustellung mit Verbraucher-Idempotenz (eindeutige Nachrichten-IDs, im Speicher dedupliziert).
- Leiten Sie unverarbeitbare Poison Pills an Dead Letter Queues (DLQs) weiter, um Partitionsstaus zu vermeiden.
Detaillierte API & Daten-Referenz
👉 API Design & Data Persistence Standards
5. Performance, Kapazität & Zuverlässigkeitstechnik
- Back-of-the-Envelope-Schätzung:
- $1\text{ Tag} \approx 10^5\text{ Sekunden}$ ($86.400\text{ s}$). $1\text{M Anfragen/Tag} \approx 12\text{ RPS}$.
- Spitzen-QPS = Durchschnitts-QPS $\times$ $3\times$.
- Cache-RAM = $20% \times (\text{Tägliches Lesevolumen} \times \text{Artikelgröße})$ (Pareto 80/20-Regel).
- Little's Law: $L = \lambda W$ (In-Flight Parallelität = Ankunftsrate $\times$ Latenz).
- Caching-Disziplin:
- Setzen Sie niemals beliebige, nicht gemessene In-Memory-TTLs, die während normaler Betriebsfenster ablaufen.
- Invalidieren Sie basierend auf Datenversionen/Fingerprints oder Sitzungszeitstempeln.
- Verteidigen Sie sich gegen Cache Stampede (Mutexe/verteilte Sperren), Cache Penetration (Bloom-Filter) und Cache Avalanche (TTL-Jitter).
- Site Reliability Engineering (SRE):
- Erzwingen Sie explizite SLOs und Latenzbudgets ($p50$, $p95$, $p99$).
- Implementieren Sie Circuit Breaker, Bulkheads und exponentielles Backoff mit vollem Jitter.
Detaillierte Referenzen zu Zuverlässigkeit & Performance
👉 Reliability, Performance & Capacity Engineering Reference
6. Architecture Decision Records (ADRs)
Dokumentieren Sie nicht-triviale technische Entscheidungen mit dem standardmäßigen ADR-Format:
- Kontext & Treiber: Das Problem, die betrieblichen Einschränkungen und die Latenz-/Skalierungsziele.
- Betrachtete Optionen: Strukturelle Alternativen und ihre Kompromisse.
- Entscheidung & Ergebnis: Konkrete Begründung, die zu den Entscheidungstreibern zurückführt.
- Konsequenzen: Explizite positive Vorteile UND negative Kosten, die akzeptiert werden.