Wir werden Weltmeister - oder warum Verantwortlichkeiten nicht nur bei CCD wichtig sind

Naja zugegeben, so weit sind wir bisher noch nicht. Aber das erste Spiel der deutschen Mannschaft war schon beeindruckend. Kein anderes Team hat so überzeugend gespielt, den Ball so schnell und flüssig laufen gelassen und dabei schöne Torchancen erarbeitet. Wie kam es dazu? Dazu kann ich zugegebenermaßen gar nicht viel sagen aber ein wichtiger Punkt hierbei ist sicher die Trennung von Zuständigkeiten. Jeder Spieler, jedes Mitglied im Trainerstab und alle anderen Beteiligten haben klare Aufgaben und keiner kümmert sich um die Angelegenheiten, die sie nichts angehen.

Single Responsibilty Principle

Genau dies ist ein Prinzip der Clean-Code-Developer. Aber was ist dies genau und wie führt dies angewendet zu besserem Code? Dazu kommen wir zurück zum Fussball:

Ich finde es gut, dass Jogi Löw sich vor Beginn der Weltmeisterschaft mit dem Verband um den Vertrag gestritten hat und es keine Lösung gibt. So muss er nicht die ganze Zeit darüber nachdenken, wie seine Entscheidungen Auswirkungen auf den Verband haben. Jetzt kann er einfach so handeln wie er möchte. Er kann jetzt einfach nur Trainer sein.

Genauso kommt er ja auch nicht auf den Gedanken, dass er besser sein könnte als Miroslav Klose und sich selbst in den Sturm stellt. Nein er trainiert und die Spieler spielen. Das können sie nämlich auch am Besten. Auch der Vorstand redet nicht mehr in die Angelegenheiten des Trainers rein. Und der Teammananger Oliver Bierhoff hat die wichtige Aufgabe die vielen Pressenanfragen von der Mannschaft und den Spielern fern zu halten, diese sollen sich ja auf ihre Sache konzentrieren.

Auswirkungen auf die Software

Stellen Sie sich folgendes vor:

Sie entwickeln ein Programm, welches unter anderem eine Berechnung durchführt und danach das Ergebnis in einem Diagramm anzeigt:




Was passiert, wenn Sie diese beiden Aspekte in einem gemeinsamen Programmteil zusammen entwickeln?

Wenn Sie die Diagrammdarstellung lesen, ändern oder erweitern möchten, so können sie die Berechnung nicht ausblenden. Sie müssen sie lesen und verstehen, weil Sie sonst bei jeder Änderung Angst haben müssen, etwas an der Berechnung kaputt zu machen. Sie können sich nicht auf ihre eigentliche Aufgabe konzentrieren und verlieren so den Fokus, verlieren an Produktionseffizienz und machen mehr Fehler, als Sie machen würden, wenn Sie sich nur auf die Diagrammdarstellung konzentrieren müssten.

Was passiert nun, wenn Sie die Diagrammdarstellung durch eine nette Animation austauschen möchten? Oder wenn Sie die Berechnung verändern müssen? Wenn Sie diese beiden Aspekte gemeinsam entwickeln, müssen Sie in beiden Fällen ihren bereits geschriebenen Code anfassen, es gibt also mehr als einen Grund diesen zu ändern. Und genau dies beschreibt Robert C. Martin in seinem Buch Agile Software Development, Principles, Patterns, and Practices als Single Responsibilty Principle: „There should never be more than one reason for a class to change.“

Dies kann aber meines Erachtens auf alle Abstraktionsebenen angewendet werden, nicht nur auf Klassen. So könnte Jogi Löw bei Unzufriedenheit mit der Leistung des Torhüters diesen auswechseln (wird bei Manuel Neuer sicher nicht passieren ;-)). Und wenn die Pressearbeit nicht so gut läuft evtl. Oli Bierhoff. Aber er muss nicht die ganze Mannschaft auswechseln, nur weil ein Teil ihm nicht gefällt. Er kann auch ganz gezielt mit den Stürmern Tore schießen üben und mit den Abwehrspielern Viererkette. Und so weiter ...

Also dann, auf dass wir Weltmeister werden oder zumindest heute drei Punkte gegen Serbien holen und ein schönes Spiel sehen werden.

Naja zugegeben, so weit sind wir bisher noch nicht. Aber das erste Spiel der deutschen Mannschaft war schon beeindruckend. Kein anderes Team hat so überzeugend gespielt, den Ball so schnell und flüssig laufen gelassen und dabei schöne Torchancen erarbeitet. Wie kam es dazu? Dazu kann ich zugegebenermaßen gar nicht viel sagen aber ein wichtiger Punkt hierbei ist sicher die Trennung von Zuständigkeiten. Jeder Spieler, jedes Mitglied im Trainerstab und alle anderen Beteiligten haben klare Aufgaben und keiner kümmert sich um die Angelegenheiten, die sie nichts angehen.

Single Responsibilty Principle

Genau dies ist ein Prinzip der Clean-Code-Developer. Aber was ist dies genau und wie führt dies angewendet zu besserem Code? Dazu kommen wir zurück zum Fussball:

Ich finde es gut, dass Jogi Löw sich vor Beginn der Weltmeisterschaft mit dem Verband um den Vertrag gestritten hat und es keine Lösung gibt. So muss er nicht die ganze Zeit darüber nachdenken, wie seine Entscheidungen Auswirkungen auf den Verband haben. Jetzt kann er einfach so handeln wie er möchte. Er kann jetzt einfach nur Trainer sein.

Genauso kommt er ja auch nicht auf den Gedanken, dass er besser sein könnte als Miroslav Klose und sich selbst in den Sturm stellt. Nein er trainiert und die Spieler spielen. Das können sie nämlich auch am Besten. Auch der Vorstand redet nicht mehr in die Angelegenheiten des Trainers rein. Und der Teammananger Oliver Bierhoff hat die wichtige Aufgabe die vielen Pressenanfragen von der Mannschaft und den Spielern fern zu halten, diese sollen sich ja auf ihre Sache konzentrieren.

Auswirkungen auf die Software

Stellen Sie sich folgendes vor:

Sie entwickeln ein Programm, welches unter anderem eine Berechnung durchführt und danach das Ergebnis in einem Diagramm anzeigt:




Was passiert, wenn Sie diese beiden Aspekte in einem gemeinsamen Programmteil zusammen entwickeln?

Wenn Sie die Diagrammdarstellung lesen, ändern oder erweitern möchten, so können sie die Berechnung nicht ausblenden. Sie müssen sie lesen und verstehen, weil Sie sonst bei jeder Änderung Angst haben müssen, etwas an der Berechnung kaputt zu machen. Sie können sich nicht auf ihre eigentliche Aufgabe konzentrieren und verlieren so den Fokus, verlieren an Produktionseffizienz und machen mehr Fehler, als Sie machen würden, wenn Sie sich nur auf die Diagrammdarstellung konzentrieren müssten.

Was passiert nun, wenn Sie die Diagrammdarstellung durch eine nette Animation austauschen möchten? Oder wenn Sie die Berechnung verändern müssen? Wenn Sie diese beiden Aspekte gemeinsam entwickeln, müssen Sie in beiden Fällen ihren bereits geschriebenen Code anfassen, es gibt also mehr als einen Grund diesen zu ändern. Und genau dies beschreibt Robert C. Martin in seinem Buch Agile Software Development, Principles, Patterns, and Practices als Single Responsibilty Principle: „There should never be more than one reason for a class to change.“

Dies kann aber meines Erachtens auf alle Abstraktionsebenen angewendet werden, nicht nur auf Klassen. So könnte Jogi Löw bei Unzufriedenheit mit der Leistung des Torhüters diesen auswechseln (wird bei Manuel Neuer sicher nicht passieren ;-)). Und wenn die Pressearbeit nicht so gut läuft evtl. Oli Bierhoff. Aber er muss nicht die ganze Mannschaft auswechseln, nur weil ein Teil ihm nicht gefällt. Er kann auch ganz gezielt mit den Stürmern Tore schießen üben und mit den Abwehrspielern Viererkette. Und so weiter ...

Also dann, auf dass wir Weltmeister werden oder zumindest heute drei Punkte gegen Serbien holen und ein schönes Spiel sehen werden.

Wir werden Weltmeister - oder warum Verantwortlichkeiten nicht nur bei CCD wichtig sind

Komponentenorientierung – CCD vs. UML

Komponentenorientierte Architekturen sind ja nichts Neues. Die Ge-sellschaft für Informatik (GI e.V.) selbst schreibt in ihrem Informatik-lexikon über Software-Architektur:

Definition (Software-Architektur)

Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.

Komponenten gehören also in die Standardwerkzeugkiste eines guten Architekten und Designers. Wie aber diese Komponenten darstellen? Ich habe den recht pragmatischen An-satz von Ralf Westphal und Stefan Lieser aus dem Clean Code Developer Camp mit der UML 2 ver-glichen und an praktischen Beispielen ausprobiert.

EInfach vs. standardisiert

Eine Notation sollte vor allem klar verständlich und eindeutig sein. Und einfach zu zeichnen vor allem bei schnellen Architekturzeichnungen am Whiteboard oder auf dem Skizzenblatt. Und genau da liegt sicherlich der Vorteil eines einfachen Ansatzes. Hier kann man schnell grobe Designs entwerfen, weglöschen verschieben usw. Wichtig ist aber, dass die Strukturen klar definiert werden. Stefan und Ralf verwenden hierbei zum Beispiel Kreise für Funktionseinheiten und einfache Pfeile für Abhängigkeiten, sowie doppelte Pfeile für Datenflüsse. Wie aber würde dies in UML aussehen? Es gibt Komponentendiagramme. Diese sind aber sehr überfrachtet mit Informationen, die ich vor allem im ersten Ansatz nicht benötige. Der Überblick auf die wichtigen Dinge geht verloren. Was aber tun, wenn der Kunde nun mal UML versteht? Warum ihm dann eine neue Notation verkaufen?

Toolunterstützung

Bei dem einfachen Ansatz gibt es bisher keine oder nur rudimentäre Unterstützung beim Entwerfen. Hier muss man auf Werkzeuge wie zum Beispiel Visio oder das Online-Tool TODO verwenden. Diese Werkzeuge haben aber den Nachteil, dass man schlecht in die Designs “hineinzoomen” kann. Aber dies ist für den schnellen Ansatz auf dem Whiteboard ja auch gar nicht nötig. Es soll einfach, schnell und nicht überfrachtet sein. Für die späteren Architekturbilder kann man dann ja immer noch auf UML zurückgreifen und zum Beispiel mit dem Enterprise Architect die Designs entwerfen. Dann bekommt man alle Vorteile der Werkzeugunterstützung.

Fazit

Ich verwende bei meinen ersten Entwürfen auf dem Skizzenblock oder Whiteboard eine einfache aber klar definierte Notation und für weitergehende Architekturdokumentation, die auch für den Kunden gedacht ist die UML 2 und die passenden Werkzeuge. Was ist eure Meinung dazu? Wie findet Ihr eine einfache Notation im Vergleich zur UML oder anderen? Über Kommentare würde ich mich freuen.

Komponentenorientierte Architekturen sind ja nichts Neues. Die Ge-sellschaft für Informatik (GI e.V.) selbst schreibt in ihrem Informatik-lexikon über Software-Architektur:

Definition (Software-Architektur)

Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.

Komponenten gehören also in die Standardwerkzeugkiste eines guten Architekten und Designers. Wie aber diese Komponenten darstellen? Ich habe den recht pragmatischen An-satz von Ralf Westphal und Stefan Lieser aus dem Clean Code Developer Camp mit der UML 2 ver-glichen und an praktischen Beispielen ausprobiert.

EInfach vs. standardisiert

Eine Notation sollte vor allem klar verständlich und eindeutig sein. Und einfach zu zeichnen vor allem bei schnellen Architekturzeichnungen am Whiteboard oder auf dem Skizzenblatt. Und genau da liegt sicherlich der Vorteil eines einfachen Ansatzes. Hier kann man schnell grobe Designs entwerfen, weglöschen verschieben usw. Wichtig ist aber, dass die Strukturen klar definiert werden. Stefan und Ralf verwenden hierbei zum Beispiel Kreise für Funktionseinheiten und einfache Pfeile für Abhängigkeiten, sowie doppelte Pfeile für Datenflüsse. Wie aber würde dies in UML aussehen? Es gibt Komponentendiagramme. Diese sind aber sehr überfrachtet mit Informationen, die ich vor allem im ersten Ansatz nicht benötige. Der Überblick auf die wichtigen Dinge geht verloren. Was aber tun, wenn der Kunde nun mal UML versteht? Warum ihm dann eine neue Notation verkaufen?

Toolunterstützung

Bei dem einfachen Ansatz gibt es bisher keine oder nur rudimentäre Unterstützung beim Entwerfen. Hier muss man auf Werkzeuge wie zum Beispiel Visio oder das Online-Tool TODO verwenden. Diese Werkzeuge haben aber den Nachteil, dass man schlecht in die Designs “hineinzoomen” kann. Aber dies ist für den schnellen Ansatz auf dem Whiteboard ja auch gar nicht nötig. Es soll einfach, schnell und nicht überfrachtet sein. Für die späteren Architekturbilder kann man dann ja immer noch auf UML zurückgreifen und zum Beispiel mit dem Enterprise Architect die Designs entwerfen. Dann bekommt man alle Vorteile der Werkzeugunterstützung.

Fazit

Ich verwende bei meinen ersten Entwürfen auf dem Skizzenblock oder Whiteboard eine einfache aber klar definierte Notation und für weitergehende Architekturdokumentation, die auch für den Kunden gedacht ist die UML 2 und die passenden Werkzeuge. Was ist eure Meinung dazu? Wie findet Ihr eine einfache Notation im Vergleich zur UML oder anderen? Über Kommentare würde ich mich freuen.

Komponentenorientierung – CCD vs. UML