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