Dies ist eine kostenlose und sehr kurze Nacherzählung des neuen Buches von Robert Martin (Onkel Bob) „Clean Architecture“, das 2018 veröffentlicht wurde.
Einführung
Softwarearchitektur ist ein bisschen wie Gebäudearchitektur. Die Gebäude haben auch eine fraktale Struktur: Gebäude bestehen aus Abteilen, Abteile bestehen aus Räumen, Räume bestehen aus Wänden, Wände bestehen aus Ziegeln. Programme hingegen bestehen aus Modulen, die aus Paketen bestehen, die aus Klassen bestehen, die aus Funktionen bestehen usw. Die Vielfalt der Programmstrukturen ist jedoch viel größer als die von Gebäuden. Daher betrachtet Onkel Bob die Softwarearchitektur als „architektonischer“ als die Gebäudearchitektur.
Darüber hinaus ist die Gebäudearchitektur im Kopf leichter zu visualisieren als die Software, da wir jeden Tag Gebäude sehen und die Architektur der Programme im Quellcode vor uns verborgen ist. Softwarearchitektur ist wie nichts.
Andererseits muss die Softwarearchitektur auch die physischen Einschränkungen berücksichtigen, da Programme auf realer Hardware mit begrenzter Leistung, Speicher, Netzwerkbandbreite usw. ausgeführt werden.
Was ist gute Architektur? Dies ist eine Architektur, die die Anforderungen von Benutzern, Geschäftsinhabern und Programmierern nicht nur zum aktuellen Zeitpunkt,
sondern auch im Laufe der Zeit erfüllt.
"Wenn Sie der Meinung sind, dass gute Architektur teuer ist, versuchen Sie es schlecht."
"Der einzige Weg, schnell zu gehen, ist, gut zu gehen."
Vorwort
Onkel Bob schreibt seit über 50 Jahren Code. Er schrieb eine Vielzahl von Programmen: groß, klein, GUI, Konsole, Web usw. Und ich bin zu dem Schluss gekommen, dass die Regeln der Architektur überall gleich sind! Und selbst über 50 Jahre haben sie sich trotz der gigantischen Steigerung der Eisenproduktivität nicht verändert.
Programmiersprachen sind auch viel besser geworden, aber die Grundkonstruktionen sind gleich geblieben: if, Zuweisung, Schleifen usw. Wenn Sie einen Programmierer aus der Mitte des letzten Jahrhunderts für ein modernes MacBook einsetzen, wird es zunächst verrückt, aber dann ist es normal, Java-Code in die Idee zu schreiben.
Aber über ein halbes Jahrhundert hat viel Erfahrung gesammelt, die noch nicht vor 50 Jahren war. Die Regeln wurden formuliert, denen dieses Buch gewidmet ist.
Einführung
Ein Arbeitsprogramm zu schreiben ist einfach. Es ist schwer
, das Programm richtig zu
schreiben . Dies erfordert Wissen, Erfahrung und Fähigkeiten, deren Entwicklung viel Zeit und Disziplin erfordert.
Wenn das Programm korrekt ausgeführt wurde, ist es einfach zu warten und Änderungen daran vorzunehmen. Es gibt einen sehr geringen Prozentsatz an Fehlern. Es braucht keine Horden von Programmierern, Tonnen von Dokumenten mit Anforderungen und ausgefeilte Tracker.
Es klingt utopisch, aber Onkel Bob hat es geschafft, an solchen Projekten zu arbeiten. Leider müssen wir in den meisten Fällen in einem schrecklichen Design arbeiten.
Was ist Design und Architektur?
Nehmen wir an, dass Design und Architektur ein und dasselbe sind.
Architektur ist nicht nur die obere Ebene, sondern die Details der oberen und unteren Ebene als Ganzes. Eins ohne das andere existiert nicht.
Ziel der Softwarearchitektur ist es
, den Personalaufwand für den Aufbau und die Wartung des erforderlichen Systems zu
minimieren .
Wenn der Aufwand gering ist und
dies während des gesamten Lebens bleibt , ist das Design gut. Wenn der Aufwand mit jeder Version zunimmt, ist das Design schlecht.
Als Beispiel zeigt Onkel Bob eine grafische Darstellung eines realen Projekts, in dem sich die Anzahl der Mitarbeiter um das 50-fache, die Anzahl der Codezeilen jedoch nur um das 2,3-fache (3M -> 7M) erhöhte. Ein beängstigenderes Diagramm ist eine Erhöhung der Kosten für eine einzelne Codezeile um das 40-fache. Das heißt, Die Produktivität ging von 100% auf fast Null zurück. Programmierer arbeiten hart, aber im Grunde kann nichts getan werden. Und jetzt das Schlimmste: Wenn wir in der ersten Version mehrere hunderttausend Dollar pro Monat an Mitarbeiter zahlen mussten, dann wurden es am Ende 20 Millionen Dollar pro Monat!
Als nächstes erinnert sich Onkel Bob an das Gleichnis von Hase und Schildkröte. Darin gewann die Schildkröte das Rennen, weil der Hase zu selbstbewusst war, ins Bett ging und das ganze Rennen durchschlief.
Das Gleiche gilt für die Entwicklung: Der Programmierer amüsiert sich mit der Zuversicht, dass er das Produkt schnell einführen und später die Ordnung wiederherstellen kann. Das Problem ist jedoch, dass er nach der Veröffentlichung das nächste Feature ausführen muss, da er sonst hinter den Wettbewerbern auf dem Markt zurückbleibt. Am Ende, in ein paar Monaten, wird seine Produktivität einfach auf Null fallen und er wird verlieren.
Anschließend gibt er ein Beispiel für ein Experiment, das von einem bestimmten Jason Gorman durchgeführt wurde, bei dem er mehrmals ein einfaches Programm schreibt. Und es stellt sich heraus, dass mit TDD das erste Mal schneller ist als sogar das dritte Mal ohne TDD. Das heißt, wenn Sie richtig schreiben, ist das Ergebnis schneller.
Der Entwickler muss für das Durcheinander verantwortlich sein, das er in das Projekt einführt. Die Qualität der Architektur muss ernst genommen werden. Dafür müssen Sie jedoch wissen, was eine gute Architektur ist.
Eine Geschichte über zwei Werte
Es gibt zwei Werte - Verhalten und Architektur.
Verhalten bedeutet, dass das Programm die funktionalen Anforderungen erfüllt und damit den Geschäftsinhabern Geld bringt. Das Problem ist, dass viele Programmierer glauben, dass dies ihre Aufgabe ist.
Der zweite Wert ist die Qualität, bei der das Programm in einem aufrechterhaltenen Zustand bleibt. Das heißt, es ist leicht zu ändern. Die Komplexität der Änderungen sollte proportional zum Ausmaß dieser Änderungen sein, nicht jedoch zu ihrer Form. Die Architektur sollte einige Formulare nicht gegenüber anderen bevorzugen, da sonst die Anforderungen der Eigentümer jedes Mal schwieriger zu implementieren sind.
Was ist wichtiger - Verhalten oder Architektur? Manager glauben, dass es wichtiger ist, dass das System funktioniert. Programmierer sollten jedoch das Gegenteil berücksichtigen, dass Architektur wichtiger ist.
Eisenhowers Matrix besagt, dass wichtig und nicht dringend eine höhere Priorität hat als dringend und unwichtig. Und Architektur ist im Gegensatz zum Verhalten immer wichtig, daher hat sie mehr Priorität.
Der Programmierer muss für die Architektur kämpfen. Ein Programmierer ist auch ein Mitglied des Geschäfts. Architektur liegt in seiner Verantwortung.
Fortsetzung folgt...