Wartbarkeit considered evil?

Vom Mythos der guten Wartbarkeit: Wie das Totschlagargument „Wartbarkeit“ Innovation verhindert

Hartmut Schlosser

(c) Shutterstock / Lucky Team Studio

Deine Lösung funktioniert zwar, aber ist sie langfristig auch gut wartbar? Dies ist ein Satz, den die meisten von Ihnen schon einmal gehört haben dürften. Sie schlagen im Planungsmeeting eine etwas unkonventionellere Lösung vor, und garantiert wird ein anderes Teammitglied die Hand zum Protest heben und das Totschlagargument der schlechten Wartbarkeit ins Spiel bringen.

Nun gilt die gute Wartbarkeit von Software sicherlich zu Recht als eine der wichtigsten Qualitäten, die Architekten stets im Auge haben sollten. Was genau aber bedeutet gute Wartbarkeit überhaupt?

Was ist „gute Wartbarkeit“?

Blogger Matt DuVall jedenfalls ist die Diskussionen um wartbare Software Leid. Nicht dass er per se keinen Wert in der Robustheit und Langlebigkeit sähe. In seiner Praxis allerdings werden unter Wartbarkeit oft ganz unterschiedliche Dinge verstanden, sodass Debatten darüber von Missverständnissen geprägt sind und im Ergebnis Innovation verhindern.

Die einen verstehen unter Wartbarkeit schlicht, dass der Code gut verständlich sein soll. Gute Lesbarkeit – in Ordnung.

Manchmal meinen Leute damit, dass der Code erweiterbar sein soll. Hier laufen Diskussionen aber Gefahr, in die Frage abzudriften, wo ein Produkt in fünf, zehn Jahren stehen soll. Die Idee,  „für alle Eventualitäten gewappnet sein zu müssen“, ist aber problematisch, denn wer weiß schon, was in fünf Jahren sein wird, in unserer schnelllebigen Branche. Matt DuVall rät, den Fokus auf die aktuellen Bedürfnisse des Unternehmens nicht zu verlieren, statt in Diskussionen über vage Zukunftsvisionen Zeit und Geld zu verlieren.

Wartbarkeit meint auch manchmal gute Abstraktionen. Auch diese haben sicherlich ihren Sinn. Doch trifft man allzu häufig auf Abstraktionen, die im Quellcode nur ein, zwei Mal vorkommen – und so quasi um ihrer selbst Willen da zu sein scheinen. Hier ruft uns DuVall ein Mantra der Rails Community in Erinnerung: „Please do Investigate“ (PDI) – neue Abstraktionsschichten einführen sollte man nur nach ausgiebigen Untersuchungen, ob die neue Schicht in der aktuellen Situation auch wirklich einen Mehrwert bringt.

Und dann sind da noch die fixen Design-Pattern, in die man ein konkretes Problem hineinzwängen möchte, um irgendwie dem Ideal einer High-Level-Architektur zu entsprechen. „Das Produkt hat ein gutes, wartbares Architektur-Design“, sagen dann die Architekten – auch wenn das zu lösende Problem eigentlich gar nicht so recht dazu passen will. Laut DuVall sind Design-Pattern nur dann gerechtfertigt, wenn sie auf die Situation abgestimmt sind und es klare Beispiele gibt, wie sie einem das Leben langfristig leichter machen.

Wartbarkeit considered evil?

Haben Sie auch schon einmal über die Wartbarkeit Ihrer Software diskutiert? Dann hilft es, sich die Vielschichtigkeit des Begriffes vor Augen zu halten, über die es sicherlich noch mehr zu sagen gibt. Einige Stichpunkte: gute Testabdeckung, automatisierte Builds, Modularität, Continuous Integration, Continuous Delivery, Abhängigkeit von externen Ressourcen, Support-Laufzeiten verwendeter Sprachversionen und Librarys, etc.

Werfen Sie angesichts der kritischen Töne aber nicht gleich alle Tugenden über Bord. Eine gute Wartbarkeit anzustreben, macht schon Sinn – für manche Projekt mehr, für manche weniger. DuVall macht nur einmal mehr auf den Fehler aufmerksam, eine Methode ungeprüft auf ein Problem anzuwenden: Schaut genau hin, ob Euer Streben nach guter Wartbarkeit nicht eurem aktuellen Business-Modell im Weg steht. Einen Freischein für’s planlose Drauflosentwickeln stellt er Ihnen ausdrücklich nicht aus:

This is not a knock on abstraction, extensibility, or software design — these ideas are at the core of our field. They help make good software great. However they are not to be presented behind the facade of maintainability, and applying these principles through guesswork is not a step towards making great software.

 

Aufmacherbild: Vector Innovation. Broken text von Shutterstock / Urheberrecht: Lucky Team Studio

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: