Softwareentwicklung kann reich machen. Menschen können sich dafür begeistern und darin zum Meister werden. Was aber immer wieder nervt, sind Fehler, im Entwickler-Volksmund auch „Bugs“ genannt (warum sie Bugs heißen, wissen Sie sicherlich schon).
Die Fehler kommen manchmal schneller als man sie beseitigen kann. Klar, es gibt gute Spezifikations- und Testverfahren wie TDD, ATDD, BDD, mit denen Entwickler Feedbackschleifen einbauen können, um Fehler so schnell wie nur irgend möglich zu bemerken. Schlägt so ein Test fehl, kann man den Bug gleich fixen, ohne dass er weiteren Schaden anrichten könnte.
Manche Bugs schlüpfen jedoch bis zum Kunden durch. Dieser bemerkt sie, meldet sie dem Support, der ihn aufnimmt und den Entwickler schon wieder etwas mehr zu tun gibt. Manchmal nimmt die Zahl der Bugs so schnell zu, dass sie nicht mehr rechtzeitig fertig werden mit dem Fixen und das Produkt langsam an Qualität verliert. Sie entscheiden sich, den Releasetermin halten zu wollen und liefern aus, inklusive Bugs. Ihre Entwickler verlieren an Kapazität, weil sie sich um Bugs kümmern müssen. Der Return on Investment pro neu eingebautes Feature lässt nach. Das ist meist der Anfang vom Niedergang eines Produktes. Diesen Anfang sollten Sie hinausschieben, zuerst so weit wie möglich und später so weit wie es geschäftlich Sinn ergibt.
Zu viele Bugs – wie kommt’s?
Bugs entstehen als unliebsame Nebenwirkung von Änderungen an der Software. Eine an sich nützliche Änderung an einer Stelle A des Programmcodes führt dazu, dass eine Stelle B sich nicht mehr so verhält wie sie soll. Offenbar muss B eine Verbindung zu A gehabt haben, sonst wäre B nicht betroffen gewesen. Als Softwarearchitekten nennen wir das Kopplung.
Eine Stelle B ist an eine Stelle A gekoppelt, um mit ihr Informationen auszutauschen oder einen Kontrollfluss auszulösen. Beispielsweise könnte ein Bug in einem Report entstehen, der Kundendaten ausgibt, weil jemand an der Struktur oder am Code für die Kundendaten etwas geändert hat, ohne an die Reports zu denken. Wir sagen, der Report ist an das Konzept Kunde gekoppelt.
David Parnas, einer der Väter des modernen Software-Engineerings, hat vier Arten der Kopplung identifiziert:
AufrufB ruft A aufErzeugungB legt ein A an, baut es zusammen und füllt es mit DatenBenachrichtigungB sendet eine Nachricht an ABesitzA ist in B enthalten, oder… A und B sind in einem gemeinsamen C enthalten
Alle diese Fälle führen dazu, dass Sie B nachtesten müssen, sobald Sie an A etwas ändern. Je mehr Kopplung Sie in das System einbauen, umso mehr Stellen gibt es, die von Änderungen betroffen sein werden und deshalb nachgetestet werden müssen.
Was können Sie tun?
Also muss es ein Ziel sein, geringe Kopplung im System zu haben. Am besten, wir eliminieren alle Arten von Kopplung, oder? Nein, im Ernst, ein System ohne Kopplung tut auch nichts mehr, was geschäftlich interessant wäre. Also müssen Sie als Entwickler oder Softwarearchitekt auf lose Kopplung achten.
Schaffen Sie Bereiche im Code, die gemeinsam etwas Sinnvolles tun, und zwar konzentriert auf ein Thema. Jeder dieser Bereiche sollte an den Rest des Codes nur über ganz definierte Wege gekoppeltsein. Rufen Sie den Rest des Codes nur über diese Wege auf, anstatt alles und jedes im System freifliegend aufzurufen. Versuchen Sie, die Zahl der Kopplungen so gering wie irgend möglich zu halten, indem Sie eindeutige Zuständigkeiten im Code schaffen und nur diese aufrufen.
Alarmsignale
Worauf müssen Sie achten, wenn Sie existierenden Code auf Kopplung untersuchen? Es gibt zwei klassische Fälle, wie man es nicht machen sollte, die immer wieder ins Auge springen. Diese werden Ihnen sicherlich schon vertraut sein:
- die „Gott“-Komponente
- die „Party“-Komponente
Die Gott-Komponente ist eine, die alles weiß und alles kann. Sie ist so interessant, dass sie von allen Seiten her aufgerufen wird und deshalb viel Kopplung erzeugt. Was ist die Folge? Kaum ändert jemand etwas an dieser Gott-Komponente, müssen alle Stellen, die Gott aufrufen, nachgetestet oder sogar angepasst werden. Meiden Sie Gott-Komponenten, indem Sie sie in kleinere zerlegen, die keine Götter mehr sind.
Die Party-Komponente ist das Gegenteil davon: Sie ist ein sehr soziales Wesen, kommuniziert und feiert gern. Sie ruft dafür viel zu viele andere auf, was wiederum viel Kopplung erzeugt. Was ist die Folge? Kaum ändert jemand etwas an einer der aufgerufenen Komponenten, schon muss die Party-Komponente nachgetestet oder sogar angepasst werden. Meiden Sie Party-Komponenten, so weit es geht. Lassen Sie Komponenten immer nur in kleinem Kreise feiern und sich ansonsten über einzelne, definierte Mitglieder mit anderen Kreisen austauschen. Dafür gibt es Muster, wie Sie das arrangieren können.
War das schon alles?
Sicherlich nicht. Leider kann ich in diesem Artikel nicht über alles schreiben, was Sie brauchen, um ein perfekt wartbares System zu haben (nicht, dass Sie das überhaupt brauchen würden, aber das steht auf einem anderen Blatt). Es gibt außer Kopplung noch mehr Probleme, auf die Sie achten müssen. Davon ein anderes Mal mehr. Wenn Sie nicht auf dieses andere Mal warten möchten, können Sie mich auch gern anrufen, dann sprechen wir darüber.
