Mit Handwerkskunst zukunftssichere Systeme bauen

Flexible Architekturen

Stefan Roock

Früher oder später werden Softwaresysteme unwartbar. Änderungen werden so teuer, dass sie faktisch unbezahlbar werden. Irgendwann werden die Schmerzen so groß, dass ein neues System entwickelt wird. Und das Spiel beginnt von vorne. Dabei handelt es sich aber nicht um ein Naturgesetz. Wir können Software entwickeln, die sich langfristig zu moderaten Kosten weiterentwickeln lässt – und das, obwohl wir auch bei der initialen Entwicklung nur moderate Kosten verursachen

Der Schlüssel zum Erfolg sind flexible Softwarearchitekturen. Sie sorgen dafür, dass sich das System leicht an die jeweiligen Anforderungen anpassen lässt. Dieser Artikel beschreibt die Grundprinzipien flexibler Softwarearchitekturen, die sich in vielen Projekten bewährt haben. Sie sind also keinesfalls neu. Wir, die Softwareindustrie, haben sie nur viel zu lange ignoriert und mit Füßen getreten. Dafür sollten wir uns schämen.

Vergurkte Systeme

Ich habe meine ersten Erfahrungen mit agiler Softwareentwicklung 1999 gemacht – konkret mit eXtreme Programming (XP). Wir waren eine Gruppe junger hochmotivierter Entwickler, die alle bereits einige Jahre Berufserfahrung hatten. Die Ansätze aus XP fühlten sich großartig an: Hochqualitative Software entwickeln, Testen, Refactoring, Pair-Programming. Tatsächlich waren wir mit XP sehr erfolgreich. Wir lieferten nützliche Software an unsere Kunden. Und wir lieferten schnell. Das war ziemlich cool. Wir hatten das Gefühl, jedes Projekt erfolgreich abwickeln zu können. Die Projekte hatten eine kurze Laufzeit von drei bis sechs Monaten und überschaubare Teamgrößen von maximal sechs Entwicklern. Mit dem Erfolg wurden die Projekte größer. Wir hatten es häufiger mit Teamgrößen mit zweistelliger Personenzahl zu tun und die Projekte liefen über Jahre.

Jetzt wurde es schmerzhaft. Die Entwicklungskosten stiegen immer weiter, und es wurde sehr teuer für uns. Zunehmender Ärger mit den Kunden wegen verpasster Termine und Fehlern in den Systemen machten die Situation nicht gerade einfacher. Für diese Probleme gab es zwei Ursachen: Erstens sind wir zu schnell vorgegangen, und zweitens haben uns zu wenig Gedanken über unser Tun und die Strukturentwicklung des Systems gemacht. Wir hatten einen zu starken Fokus darauf, möglichst schnell zu liefern. Wir waren waghalsig. Zweitens waren wir unwissend. Die Universität hatte uns nicht ausreichend ausgebildet, um nicht-triviale Softwaresysteme zu entwickeln. Und die Unternehmen, in denen wir während und nach dem Studium gearbeitet hatten, haben das auch nicht getan. XP hatte zwar Referenzen auf Techniken wie testgetriebene Entwicklung und Refactoring gesetzt, aber ausreichend verstanden hatten wir diese nicht. Zusammengefasst:

Immerhin erkannten wir schnell, dass wir Probleme hatten. Wir investierten in die Ausbildung und lernten echte testgetriebene Entwicklung (TDD, mehr dazu unten) und echtes Refactoring (unter anderem lernten wir, was man alles mit den automatisierten Refactorings der Entwicklungsumgebungen erreichen kann). Beim Erlernen dieser Techniken haben uns Coding-Dojos (mehr dazu weiter unten) geholfen, die eine effektive Lernumgebung herstellen.

Und passend zu den Entwicklungstechniken lernten wir Entwurfsprinzipien wie das Dependency Inversion Principle einzusetzen. Es füllten sich die Lücken in unserem Verständnis, und wir wurden bessere Entwickler. Wir wurden wissend. Allerdings hatten wir immer noch einen zu starken Fokus auf schnelle Lieferung und das Einhalten von Terminen. Wir lieferten schlecht wartbare Systeme, obwohl wir wussten, wie es besser geht. Wir waren immer noch waghalsig.

Geschrieben von
Stefan Roock
Kommentare

Schreibe einen Kommentar

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