Eine der am häufigsten gestellten Fragen der Entwickler, mit denen ich zusammengearbeitet habe, lautet: Wie wird man Softwarearchitekt? und damit verbunden die Erste Schritte zum Softwarearchitekten. Darauf eine gute Antwort zu geben, ist nicht simple. Dies lag zum Teil an der bekannten Schwierigkeit, eindeutig zu definieren, was ein Softwarearchitekt tut. Ein weiterer Teil ist, dass meine Reise viele Jahre gedauert hat und nicht von Anfang an mit der Absicht begonnen hat. Also machte ich mich daran, beides so gut wie möglich zu lösen.
In der Vergangenheit habe ich meine Meinung darüber, was ein Softwarearchitekt tut – oder tun sollte – auf der Grundlage früherer Ergebnisse und einiger Prinzipien geteilt, mit denen ich mich stark verbunden fühle, wie z. B. kontinuierliches Lernen, sich relevant zu machen und nach vorne zu blicken, ohne die Realität aus den Augen zu verlieren.
Mit dieser Definition, wenn auch persönlich und unvollkommen, hatte ich das Gefühl, dass der erste Teil angesprochen wurde, was mich dann dazu veranlasste, eine bessere Antwort zu suchen: „Was ist der Weg, den ich einschlagen sollte, um das Ziel zu erreichen?“. Für mich bedeutet das unveränderlich vor allem eines: Weiterbildung! Ich schaute mir die aktuelle Landschaft an und wählte eine Liste von Büchern aus, von denen ich glaubte, dass sie das Thema direkt ansprechen oder nicht.
In diesem Artikel werde ich meine Rezension eines dieser Bücher teilen, was meiner Meinung nach einer der ersten Schritte für jeden sein sollte, der sich für einen Wechsel in eine Position als Softwarearchitekt entscheidet.
Grundlagen der Softwarearchitektur: Ein ingenieurwissenschaftlicher Ansatz
Dieses Buch (hier gibt es die deutsche Übersetzung davon), geschrieben von Mark Richards und Neal Ford, erregte meine Aufmerksamkeit wegen seiner Prämissen, eines Blicks auf die Grundlagen – auch bekannt als die Grundlagen – die man verstehen sollte, und auch den technischen – oder objektiveren – Ansatz zur Entscheidungsfindung.
Jeder Aspekt ist wichtig, wobei die grundlegende Natur bestimmt, welche Bereiche Sie kennen sollten, wenn Sie es mit Ihrer Entscheidung, Architekt zu werden, ernst meinen. Der technische Ansatz manifestiert sich in Konzepten, die Sie anwenden sollten, um die subjektive Natur der Lösungsauswahl zu reduzieren, mit der Sie unweigerlich konfrontiert werden.
Das Buch ist in 3 Teile unterteilt: Grundlagen, Architekturstile und -techniken sowie Soft Skills.
Schauen wir uns diese Teile und einige ihrer Highlights an.
Grundlagen
Nichts ist besser geeignet, um die Reise zu beginnen, als vorzuschlagen, was architektonisches Denken ist und wie Sie wahrscheinlich technische Breite und Tiefe abwägen müssen. Es ist das erste Mal in diesem Buch, dass wir daran erinnert werden, dass „alles in der Softwarearchitektur ein Kompromiss ist“, was eine neue Dimension sein kann, die hinzugefügt werden kann, wenn Sie ein zu implementierendes Design auswählen. Wir sollten verstehen, dass die Verantwortlichkeiten eines Architekten eine Sammlung von technischen Fähigkeiten, operativem Bewusstsein, Soft Skills und Politik erfordern, um es gelinde auszudrücken.
Eines der Highlights dieses Abschnitts ist die Präsentation, was die Softwarearchitektur definieren sollte:
- Die Struktur (das zu verwendende Architektursystem)
- Die Architekturmerkmale (die -ilities — Skalierbarkeit, Verfügbarkeit, etc.)
- Die Architekturentscheidungen (die Regeln, die wir bei der Implementierung befolgen sollten)
- Die Designprinzipien (die Leitlinien, die bei der Entscheidungsfindung helfen)
Dieser „Rahmen“ kann verwendet werden, um dem Publikum (Entwicklern, Architekten) die Grenzen zu verdeutlichen, damit sich jeder auf das konzentrieren kann, was er am besten kann, während er auf die Ziele ausgerichtet ist.
Eine weitere einfache, aber wirkungsvolle Erinnerung ist, dass für einen Softwarearchitekten das „Warum wichtiger ist als das Wie“. Das bedeutet nicht, dass wir die Realitäten und Grenzen der Technologie und unseres Kontexts ignorieren werden, aber wir sollten zuerst den Grund beherrschen, der uns dazu antreibt, etwas zu tun.
In den meisten Fällen werden Sie feststellen, dass Sie die „richtige“ Lösung für das „falsche“ Problem geliefert haben 🙂
Modularität
Als nächstes wird die Modularität vorgestellt, wobei der Schwerpunkt auf der Definition dessen liegt, was sie ist und wie sie gemessen werden kann. Die Messung der Kohäsion und Kopplungstechniken sollten Sie im Visier haben, wobei LCOM (Lack of Cohesion in Methods) für Kohäsion und Abstraktheit, Instabilität und Entfernung von der Hauptsequenz für die Kopplung vorgeschlagen wird.
Es ist schwierig, die Architekturmerkmale zu erfassen, da es so viele davon gibt und einige implizit sind. Das erfordert, dass Sie in der Lage sind, sie aufzudecken und zu priorisieren, bevor Sie mit einer echten Implementierung beginnen.
Explizite Merkmale sind einfacher, da sie in den Anforderungen für das Projekt/System, an dem Sie arbeiten werden, erwähnt werden. Andere, wie z. B. die Verfügbarkeit, ergeben sich in der Regel aus der Interaktion mit den Stakeholdern und der kontinuierlichen Erweiterung Ihres Wissens (das Warum).
Es reicht jedoch nicht aus, die Eigenschaften und Entscheidungen zu definieren, da sie für sich genommen nur Wörter sind, die übersehen oder vergessen werden können. Im Idealfall sollten wir Wege finden, um zu messen und zu regeln, ob diese befolgt werden. Dinge wie CC (Cyclomatic Complexity) und Fitnessfunktionen sind deine Verbündeten in diesem Kampf.
Das übergeordnete Ziel ist es, automatisierte Wege zu finden, um Abweichungen zu erkennen, damit darauf reagiert werden kann. Wenn Sie sich z. B. für die Verwendung von Schnittstellen in Ihren Anwendungsdiensten entscheiden, können Sie eine Fitnessfunktion schreiben, die den Code scannt und prüft, ob er direkt verwendet wird, und Verstöße meldet.
Wenn Sie als Architekt eine Aufteilung der Verantwortlichkeiten in Komponenten vorschlagen, haben Sie zwei Möglichkeiten: Sie konzentrieren sich auf den technischen Aspekt oder führen eine Domänenpartition durch. Hier werden sich diejenigen, die DDD (Domain-Driven Design) folgen, wahrscheinlich zu Hause fühlen, mit einem klaren Wertversprechen zur Verwendung des Domain-Flavors.
Architekturstile
In diesem Teil werden verschiedene Architekturstile vorgestellt, von monolithisch bis verteilt. Es dient als gute Einführung in viele Möglichkeiten, wie Sie Ihre Architekturinfrastruktur definieren können.
Ausgehend von den monolithischen untersuchen wir die Layer-, Pipeline- und Mikrokernel-Architekturen. Von „verteilt“ haben wir eine ähnliche Behandlung für die servicebasierte, ereignisgesteuerte, spaced-basierte, serviceorientierte und Microservice-Architektur.
Einige dieser Stile mögen sehr ungewöhnlich sein, für mich war der raumbasierte einer davon, aber für jeden können wir seine Topologie finden, wie er sich verhält, und eine Klassifizierung für:
- Art der Partitionierung
- Anzahl der Quanten
- Einsatzfähigkeit
- Elastizität
- Evolutionär
- Fehlertolerant
- Modularität
- Gesamtkosten
- Leistung
- Zuverlässigkeit
- Skalierbarkeit
- Einfachheit
- Testbarkeit
Obwohl ich es äußerst selten finde, dass Sie mit jedem einzelnen Architekturstil arbeiten, können Sie von einer Einführung in eine breitere Realität profitieren. Ich finde eine Reihe von Entwicklern, die in der Vergangenheit nur mit Microservices oder Layering gearbeitet haben.
Selbst wenn Sie mit der vorgeschlagenen Punktzahl nicht einverstanden sind, gibt sie Ihnen zumindest einen Bezugsrahmen, in dem Sie sich Ihre eigene einfallen lassen können!
Techniken & Soft Skills
Dieser Teil zeigt einige leicht verständliche Techniken, die Sie im Umgang mit den vielen Herausforderungen anwenden können, denen Sie als Architekt gegenüberstehen.
Es beginnt mit einigen Anti-Patterns, die Sie kennen und vermeiden sollten, wenn Sie Architekturentscheidungen treffen. Geschäftliche Begründungen wie Kosten, Markteinführungszeit, Benutzerzufriedenheit und strategische Positionierung sollten identifiziert und als Entscheidungshilfe herangezogen werden.
Letztendlich ist es wichtig, die geschäftlichen Stakeholder zu verstehen und zu berücksichtigen. Wenn Sie Ihre Entscheidung auf einen bestimmten Faktor, wie z. B. die Kosten, stützen, ist sie möglicherweise nicht ausgerichtet, wenn die Stakeholder die Markteinführungszeit bevorzugen.
Die Verwendung von ADRs (Architecture Decision Records) wird empfohlen, um sicherzustellen, dass diese Entscheidungen leicht gefunden und referenziert werden können. Damit werden die Diskussion zu reduzieren oder zumindest die Gründe der Vergangenheit offenzulegen.
Risiko ist etwas, das jeder Architektur, die wir entwickeln, inhärent ist, also wie bewerten wir es? Nun, eine Risikomatrix ist hilfreich, da sie die Gesamtauswirkungen und die Wahrscheinlichkeit enthält, dass dieses Risiko für eines der Merkmale Ihrer Architektur auftritt. Es wird ein Fünf-Faktoren-Rahmen vorgeschlagen, der bei der Anpassung der Kontrolle helfen soll, die der Architekt anwenden sollte.
Als Architekt werden Verhandlungen Teil Ihrer täglichen Arbeit sein, sei es mit Entwicklern oder anderen Stakeholdern. Es ist wichtig, in der Lage zu sein, zuzuhören und die Prinzipien hinter den getroffenen Entscheidungen zu präsentieren.
Als Inspiration dient ThoughtWorks Tech Radar. Die Erstellung Ihres persönlichen Radars kann Ihnen dabei helfen, die Themen abzustimmen, auf die Sie sich als nächstes auf Ihrem kontinuierlichen Lernpfad konzentrieren sollten.
Fazit
Insgesamt hat dieses Buch festgehalten, was ich als die ersten Schritte betrachte, von einer Definition, was Architektur enthalten sollte, welche Rolle ein Architekt spielen sollte, bis hin zu Tipps und praktischen Werkzeugen, die jeder nutzen kann, um Qualität und Effektivität zu verbessern.
Aber wir sind noch nicht fertig, denn es gibt andere Aspekte, die nicht in dem Buch behandelt werden, die Teil des Werkzeuggürtels des Architekten sein sollten. Aber dazu später.
Weitere interessante Beiträge: Swark: Automatische Architekturdiagramme aus Code und Python 3.14: Die 5 wichtigsten Funktionen