Flexible Architekturen: Mit Handwerkskunst zukunftssichere Systeme bauen

Programmieren lernen

Die schlechte Nachricht ist, dass die meisten Informatikabsolventen von Universitäten und Fachhochschulen nur rudimentär programmieren können. Noch schlechter ist, dass sie es nicht wissen. Und noch mal schlechter ist, dass die Unternehmen, die diese Absolventen einstellen, das auch nicht wissen oder nicht wahrhaben wollen.

Die gute Nachricht ist, dass die meisten Absolventen das Programmieren lernen können. Und das funktioniert „On the Job“ alleine meistens nicht so gut. Eingebunden in ein Projekt fehlt der Freiraum für Experimente und die Zeit für das notwendige Reflektieren. Mit den Code-Katas und dem Code-Dojo haben sich in den letzten Jahren zwei Techniken entwickelt, mit denen man seine eigenen Programmierfähigkeiten gut verbessern kann.

Code-Katas sind kleine Programmieraufgaben (z. B. Primfaktorzerlegung), die man immer wieder programmiert – so wie man im Karate auch dieselbe Kata immer wieder übt [10]. Das Ziel ist dabei nicht, die Code-Kata möglichst schnell abzuhaken. Das Ziel ist, den perfekten Code mit dem perfekten Vorgehen zu produzieren. Dieses Ziel wird man nie erreichen, aber mit jeder Wiederholung der Kata wird man ein wenig besser. Code-Katas eignen sich z. B. auch hervorragend, um seine TDD-Fähigkeiten zu verbessern.

Coding-Dojos werden mit mehreren Entwicklern durchgeführt. Typischerweise arbeiten zwei Entwickler im Pair Programming an einem Rechner, dessen Bildschirminhalt per Beamer für die anderen Teilnehmer projeziert wird. Alle fünf Minuten wechselt ein Pair-Partner zurück ins Publikum, und ein Entwickler aus dem Publikum wird neuer Pair-Partner. Das Ziel ist, von anderen durch Zuschauen zu lernen. Dass beim Coding-Dojo Pair Programming eingeübt wird, ist ein angenehmer Nebeneffekt.

Entkopplung

Entkopplung ist essenziell für flexible Architekturen. Nur entkoppelte Systeme lassen sich leicht ändern. Nur bei ihnen haben Änderungen begrenzte Auswirkungen. Bei stark gekoppelten Systemen betreffen viele Änderungen über den so genannten Ripple-Effect [11] große Teile des Systems. Damit werden die meisten Änderungen sehr teuer, und agiles Vorgehen funktioniert nicht mehr.

Richtiges TDD führt zu Entkopplung, weil es dazu zwingt, mit Mocks zu testen [5], [12] und an den richtigen Stellen Interfaces einzuziehen. Neben dem TDD-Vorgehen ist das Dependency Inversion Principle (DIP) ein wichtiges Entwurfsprinzip, um Entkopplung herzustellen. Dass Robert Martin das DIP bereits 1996 beschrieben hat, wirft kein gutes Licht auf unsere Zunft (Zeitzeugen führen das Prinzip sogar bis auf das Jahr 1992 zurück [13]). 18 Jahre haben wir gebraucht, bis dieses Prinzip etwas bekannter geworden ist. In Kurzform sagt das DIP aus, dass High-Level-Konzepte nicht von Low-Level-Details abhängig sein sollen. Allen Bemühungen um die perfekte Kapselung in objektorientierten Systemen zum Trotz betreffen viele Änderungen nicht nur die interne Implementation einer Klasse, sondern auch deren Schnittstelle. Man sollte seine Abhängigkeitsstruktur also so entwerfen, dass die Komponenten mit der niedrigsten Änderungsfrequenz von keinen anderen Komponenten abhängen. Die Komponenten mit der höchsten Änderungsfrequenz dürfen hingegen von anderen Komponenten abhängen. Typischerweise ändern sich Low-Level-Details häufiger als High-Level-Konzepte, sodass man die normalerweise vorhandene Abhängigkeit der High-Level-Konzepte von den Low-Level-Details umdrehen sollte. Der Kunde darf also nicht KundeDBFinder kennen, der Kunden in der Datenbank sucht. Stattdessen sollte KundeDBFinder den Kunden kennen. Viele Entwickler meinen jetzt, dass es gar nicht möglich ist, die Beziehungen umzudrehen. Das ist allerdings nur ein weiterer Beleg dafür, wie schlecht es um die programmiertechnische Ausbildung in den Universitäten und Fachhochschulen steht. Der wesentliche Grund, das Konzept des Interfaces in einer Programmiersprache anzubieten, ist der Wunsch, Abhängigkeiten umdrehen zu können. Viele der Entwurfsmuster von Gamma et. al. [14] basieren auf dieser Idee.

Der komponentenorientierte Architekturstil Quasar macht massiv Gebrauch vom DIP [15] und bildet auch die technologischen Festlegungen aus der Architekturvision über so genannte Komponenten der Kategorie 0 ab. Wir haben DIP und Quasar erfolgreich in agilen Projekten eingesetzt. Dabei zeigte sich, dass Quasar das Testen mit Mocks an den richtigen Stellen erzwingt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.