- An der tatsächlichen Gestaltung großer Systeme können nur Ingenieure mitwirken, die den betreffenden Code selbst bearbeiten, abstrakte Ratschläge sind meist bedeutungslos
- Allgemeine Designratschläge (generic design) werden oft gegeben, obwohl man die Codebasis nicht kennt und nur die Domäne versteht
- In der Praxis sind konkrete Einschränkungen und die Wahrung von Konsistenz viel wichtiger als Designprinzipien, und entscheidend ist das Verständnis des aktuellen Zustands des Codes
- Beim Entwurf neuer Systeme oder bei Entscheidungen über die technische Ausrichtung eines ganzen Unternehmens können allgemeine Designprinzipien teilweise nützlich sein
- Doch architektenzentrierte Designstrukturen, die vom praktischen Geschehen getrennt sind, scheitern leicht, und die Person, die ein Design vorschlägt, sollte die Verantwortung für das Ergebnis tragen
Grenzen allgemeiner Softwaregestaltung
- Für den Entwurf großer Systeme ist ein tiefes Verständnis der konkreten Details des Codes unverzichtbar
- Abstrakte Ratschläge helfen bei der Lösung realer Probleme kaum
- In der Praxis ist Konsistenz (consistency) wichtiger als „gutes Design“
- Da reale Codebasen komplex sind und unvorhersehbare Folgen erzeugen, sind die wählbaren Implementierungswege für sichere Änderungen begrenzt
- Große gemeinsam genutzte Codebasen befinden sich immer in einem Zwischenzustand, in dem mehrere Designs vermischt sind; wichtiger als ein ideales Ziel ist der aktuelle Grad der Verkopplung im Code
- Da bei den meisten Systemen ein vollständiges Rewrite unmöglich ist, muss man sich auf interne Konsistenz und die Sorgfalt der Ingenieure verlassen
Merkmale konkreter Softwaregestaltung
- Effektive Designdiskussionen entstehen in Gesprächen zwischen wenigen Ingenieuren, die das System täglich bearbeiten
- Dabei geht es nicht um allgemeine Prinzipien, sondern um konkrete Kontexte wie die Detailstruktur des Systems oder Datenflüsse
- Diskutiert wird zum Beispiel nicht „Ist DRY gut?“, sondern eher feingranular technisch, etwa: „Kann diese Funktion in Subsystem A untergebracht werden?“ oder „Sind Informationen aus B im Kontext von C zugänglich?“
- Wichtige Beiträge bestehen darin, kleine Missverständnisse oder die Detailauswirkungen von Codeänderungen zu korrigieren
Wann allgemeine Designratschläge nützlich sind
- Beim erstmaligen Entwurf eines neuen Projekts sind allgemeine Prinzipien nützlich, weil es noch keine konkreten Einschränkungen gibt
- Wenn die Wahl zwischen mehreren Implementierungsoptionen schwerfällt, können allgemeine Prinzipien als Entscheidungskriterium (tie-breaker) dienen
- Sie helfen auch dabei, Konsistenz auf Unternehmensebene zu wahren; das ist eine der formellen Rollen von Softwarearchitekten
- Auch bei weitreichenden Technologieentscheidungen wie Cloud vs. On-Premises, AWS vs. Azure können allgemeine Prinzipien als Orientierung dienen, dennoch dürfen konkrete Einschränkungen nicht ignoriert werden
Architekten und das Problem des „lokalen Minimums“
- Viele Unternehmen geraten in abstrakte, architektenzentrierte Designstrukturen ohne Praxiserfahrung vor Ort
- Dieser Ansatz wirkt auf den ersten Blick effizient, führt in Wirklichkeit aber zu Designs, die die Ingenieure vor Ort nicht umsetzen können
- Da Architekten nicht selbst implementieren, fehlt oft Verantwortung für das Ergebnis (skin in the game)
- Wenn ein Design erfolgreich ist, können sie den Ruhm beanspruchen; scheitert es, kann die Ausführung dem Umsetzungsteam angelastet werden
- Solche Strukturen neigen dazu, formale Designaktivitäten stärker zu fördern als tatsächlichen Wert
Fazit und Vorschlag
- Nützliche Designdiskussionen finden als konkrete Gespräche auf Code-Ebene statt, und der Designer muss mit der Codebasis vertraut sein
- Allgemeine Architekturprinzipien sollten auf den Entwurf neuer Systeme, die Unterstützung detailbezogener Entscheidungen in bestehenden Systemen und die Festlegung der technischen Richtung auf Unternehmensebene beschränkt bleiben
- Wer ein Projektdesign vorschlägt, sollte Verantwortung für dessen Erfolg und Misserfolg tragen, und Ingenieure, die tatsächlich am Code arbeiten, sollten die Hauptakteure des Designs sein
- So können Menschen, die das reale System verstehen und deployen können, als die eigentlichen Designer anerkannt werden
Noch keine Kommentare.