1.1  Was bedeutet Wartbarkeit überhaupt?

‌Bevor Sie mich für verrückt erklären und versuchen, das Buch zurückzugeben, lassen Sie mich Ihnen erklären, was ich mit Wartbarkeit meine.

Wartbarkeit ist nur eine der vielen Qualitätsanforderungen, die potenziell eine Softwarearchitektur ausmachen. Ich habe ChatGPT nach einer Liste von Qualitätsanforderungen gefragt und folgendes Ergebnis erhalten:

• Skalierbarkeit

• Flexibilität

• Wartbarkeit

• Sicherheit

• Zuverlässigkeit

• Modularität

• Performance

• Interoperabilität

• Testbarkeit

• Kosteneffizienz

Und das ist nur eine kleine Auswahl.[1]

Als Softwarearchitekten entwerfen Sie Ihre Software so, dass sie die Qualitätsanforderungen erfüllt, die für die Software am wichtigsten sind. Für eine Trading-Anwendung mit hohem Durchsatz würden Sie sich zum Beispiel auf Skalierbarkeit und Zuverlässigkeit konzentrieren. Befasst sich die Anwendung mit persönlichen Informationen in Deutschland, müsste die Sicherheit an erster Stelle stehen.

Ich glaube, dass es falsch ist, die Wartbarkeit mit den restlichen Qualitätsanforderungen in einen Topf zu werfen, da Wartbarkeit etwas Besonderes ist. Ist eine Software wartbar, dann bedeutet dies, dass sie leicht zu ändern ist. Ist sie leicht zu ändern, dann ist sie flexibel und vermutlich auch modular. Wahrscheinlich ist sie auch kosteneffizient, da leichte Änderungen gleichbedeutend sind mit günstigen Änderungen. Ist sie wartbar, kann man sie vermutlich weiterentwickeln, sodass sie skalierbar, sicher, zuverlässig und performant ist, wenn sich das alles als notwendig erweisen sollte. Man kann die Software so verändern, dass sie mit anderen Systemen interoperabel wird, weil dies leicht zu ändern ist. Und schließlich impliziert die Wartbarkeit auch eine Testbarkeit, da wartbare Software mit hoher Wahrscheinlichkeit aus kleineren und einfacheren Komponenten besteht, die das Testen erleichtern.

Sie erkennen sicher, was ich hier gemacht habe. Ich habe die KI nach einer Liste von Qualitätsanforderungen gefragt und diese dann alle wieder auf Wartbarkeit zurückgeführt. Mit ähnlich plausiblen Argumenten könnte ich vermutlich noch viel mehr Qualitätsanforderungen an Wartbarkeit koppeln. Das ist natürlich ein bisschen vereinfacht, aber im Kern stimmt es: Wenn die Software wartbar ist, dann ist es einfacher, sie in alle Richtungen weiterzuentwickeln, funktional und nichtfunktional. Und wir alle wissen, dass Änderungen im Leben eines Softwaresystems unausweichlich sind.

1.2  Wartbarkeit führt zu Funktionalität

Kommen wir zurück zu meiner Behauptung vom Anfang dieses Kapitels, dass Wartbarkeit wichtiger ist als Funktionalität‌‌.

Fragen Sie einen Produktmenschen, was an einem Softwareprojekt am wichtigsten ist, dann wird er oder sie Ihnen sagen, dass der Wert, den die Software den Benutzern bietet, die wichtigste Sache ist. Mit Software, die ihren Benutzern keinen Wert bietet, ist kein Geld zu verdienen. Und ohne zahlende Benutzer gibt es kein funktionierendes Geschäftsmodell, das das wesentliche Maß für den Erfolg im Geschäftsleben ist.

Die Software muss also einen Wert bieten. Dies darf sie aber nicht auf Kosten der Wartbarkeit tun.[2] Denken Sie einmal darüber nach, wie viel effizienter und befriedigender es ist, Funktionalität zu einem Softwaresystem hinzuzufügen, das leicht zu ändern ist, als zu einem, bei dem Sie sich zeilenweise durch den Code kämpfen müssen! Ich bin mir ziemlich sicher, dass auch Sie schon einmal an einem dieser Softwareprojekte mitgearbeitet haben, bei denen es so viel überflüssigen Kram im Code gibt, dass es Tage oder Wochen dauert, um ein Feature zu entwickeln, das eigentlich nur ein paar Stunden zur Fertigstellung brauchen sollte.

Entsprechend ist Wartbarkeit also eine entscheidende Stütze für die Funktionalität. Schlechte Wartbarkeit bedeutet, dass Änderungen in der Funktionalität mit der Zeit immer teurer werden, wie Abbildung 1.1 zeigt:

In einem weniger gut wartbaren Softwaresystem werden Änderungen an der Funktionalität schon bald so teuer, dass jede Änderung ein Ärgernis wird. Die Produktleute beschweren sich bei den Entwicklern über die Kosten der Änderungen. Die Entwickler verteidigen sich wiederum damit, dass die Auslieferung neuer Features immer eine höhere Priorität hatte als die Verbesserung der Wartbarkeit. Mit zunehmenden Änderungskosten steigt auch die Wahrscheinlichkeit von Konflikten.

Wartbarkeit ist ein Friedensstifter. Sie ist umgekehrt proportional zu den Kosten von Änderungen und daher auch zur Wahrscheinlichkeit eines Konflikts. Haben Sie schon einmal darüber nachgedacht, die Wartbarkeit eines Softwaresystems zu verbessern, nur um einen Konflikt zu vermeiden? Ich denke, das allein ist schon eine gute Investition.

Was ist jedoch mit den großen Softwaresystemen, die trotz ihrer schlechten Wartbarkeit ‌erfolgreich sind? Es stimmt, dass es kommerziell erfolgreiche Softwaresysteme auf dem Markt gibt, die kaum gewartet werden können. Ich habe an Systemen gearbeitet, bei denen das Hinzufügen eines einzigen Feldes zu einem Formular ein Projekt war, das Wochen an Entwicklerzeit kostete – und der Kunde hat meinen geforderten Stundensatz bezahlt, ohne mit der Wimper zu zucken.

Diese Systeme fallen üblicherweise in eine von zwei Kategorien (manchmal auch in beide):

• Sie sind am Ende ihres Lebens, sodass nur noch ausgesprochen selten Änderungen an ihnen vorgenommen werden.

• Sie werden von einem finanziell gut aufgestellten Unternehmen gestützt, das bereit ist, Geld in das Problem zu stecken.

Selbst wenn ein Unternehmen viel Geld aufwenden kann, erkennt es normalerweise, dass es die Wartungskosten reduzieren könnte, indem es in die Wartbarkeit investiert. Üblicherweise sind in solchen Unternehmen daher bereits Initiativen auf dem Weg, um die Software besser wartbar zu machen.

Sie sollten sich immer um die Wartbarkeit der Software sorgen, die Sie entwickeln, damit diese nicht zu dem gefürchteten Big Ball of Mud‌ (einer großen Matschkugel) degeneriert. Falls Ihre Software jedoch nicht in eine der zwei genannten Kategorien fällt, müssen Sie sich sogar noch mehr Sorgen um sie machen.

Heißt das, Sie brauchen viel Zeit, um eine wartbare Architektur zu planen, bevor Sie überhaupt mit dem Programmieren beginnen? Müssen Sie ein Big Design Up Front (BDUF)‌ – eine vorher festgelegte Architektur – schaffen, was oft mit der Wasserfall-Methode gleichgesetzt wird?! Nein, das müssen Sie nicht. Aber Sie müssen zumindest ein bisschen was an Architektur planen (vielleicht sollten wir dies dann Some Design Up Front bzw. SDUF nennen?), um den Samen der Wartbarkeit in die Software einzupflanzen, der es Ihnen erleichtern dürfte, die Architektur mit der Zeit in die gewünschte Richtung zu entwickeln.

Teil dieses Vorab-Designs ist die Wahl eines Architekturstils‌, der den Rahmen für die Software definiert, die Sie entwickeln. Dieses Buch wird Ihnen helfen zu entscheiden, ob eine Clean Architecture – oder Ports-und-Adapter-/Hexagonale-Architektur – für Ihren Kontext eine gute Entscheidung ist.

1.3  Wartbarkeit erzeugt Entwicklerfreude

‌Würden Sie als Entwicklerin oder Entwickler lieber an Software arbeiten, bei der Änderungen einfach sind, oder an Software, bei der Änderungen schwer sind? Nicht antworten, es ist eine rhetorische Frage!

Abgesehen vom direkten Einfluss auf die Änderungskosten hat Wartbarkeit ‌noch einen weiteren Vorteil: Sie macht Entwickler glücklich (oder zumindest macht sie sie weniger traurig – je nachdem, wie das aktuelle Projekt gerade läuft).

Der Begriff, mit dem ich dieses Glück beschreiben möchte, lautet Developer Joy‌, also quasi Entwicklerfreude‌. Man...