Herbert Dowalil Selbstständig

Strukturelle Qualität ist das wichtigste Merkmal langlebiger Softwarearchitekturen.

Angemessene Strukturen und gut voneinander abgegrenzte einzelne Komponenten sind bestimmt das wichtigste Merkmal eines gut wartbaren und langlebigen Softwaresystems. Bei schlecht strukturiertem Code tauchen immer wieder die gleichen Schwierigkeiten auf. Aber es gibt natürlich verschiedene Möglichkeiten, diese in den Griff zu bekommen. Microservices sind dabei nur eine Antwort von vielen.

Lassen Sie mich mit einem Szenario beginnen, das ich im Zuge meiner Coachingtätigkeit so oder so ähnlich schon einige Male erlebt habe: Im Zuge der Einführung einer neuen Version eines Softwarepakets kommt es zu Problemen. Manchmal in Teilen der Software, die gar nicht geändert wurden. Das Management ist sehr unglücklich über diese Situation und verlangt nach mehr Unit-Tests in der Hoffnung, damit die unerwünschten Seiteneffekte der Änderungen in den Griff zu bekommen. Das Team tut sich aber mit dieser Art der Testautomatisierung aus irgendeinem Grund schwer.

Die Probleme, die man in so einer Situation mit der Codebasis hat, lassen sich meiner Erfahrung nach nicht mit Technik allein lösen. Im Zuge einer Verbesserung ist auch ein kultureller Wandel im Entwicklerteam nötig. Wie schwierig so etwas sein kann, darf dabei nicht unterschätzt werden. Auch wenn die bestehende Entwicklermannschaft den Legacy-Code nur geerbt hat und es gerne schon immer anders gemacht hätte. Am besten geht der kulturelle Wandel im Team dabei Schritt für Schritt mit der Verbesserung der Codebasis einher. Zur Unterstützung möchte ich an dieser Stelle eine Lanze für die Clean-Code-Developer-Initiative von Ralf Westphal und Stefan Lieser brechen. Um ein neues Wertesystem zu verinnerlichen, genügt es nämlich nicht, ein paar Regeln auswendig zu lernen. Deshalb ist es am besten, die Entwicklung in einzelne Stufen zu unterteilen, die von den Entwicklern eine nach der anderen erklommen werden. Jeder Entwicklungsstufe ist dabei eine Farbe zugeordnet. Wer möchte, trägt ein Armband in der jeweiligen Farbe, die dem Grad entspricht, an dem er gerade arbeitet. An jeder Stufe sollte man dabei für mindestens drei Wochen arbeiten, um die diversen Prinzipien auch wirklich zu verinnerlichen. Wer am ersten, roten Grad arbeitet, beschäftigt sich dabei beispielsweise mit DRY (Don’t repeat yourself) und KISS (Keep it simple and stupid). In dieser ersten Phase lernt man bereits auch Uncle Bobs Developer Boy Scout Rule kennen, die man zu Beginn jeder kontinuierlichen Verbesserung verinnerlicht haben sollte: „Always leave the code behind in a better state than you found it.“

Das Dilemma mit den Unit-Tests

Aber warum ist es so schwierig, für Legacy-Code Unit-Tests zu schreiben? Zu diesem Problem kommt es, weil sich einzelne Teile des Codes (Klassen, Packages und Module) nicht sauber durch ihre ein- und ausgehenden Schnittstellen vom Rest des Systems abgrenzen. Das macht also nicht nur die Wartung der Codebasis generell schwierig, sondern vermindert obendrein noch die Testbarkeit des Systems. Falls Ihnen das bekannt vorkommt, befinden Sie sich vermutlich in einem so genannten Legacy-Code-Dilemma.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 11.17 - "Per Anhalter durch das Cloud-Universum"

Alle Infos zum Heft
579813086Langlebigkeitstherapien für monolithische Legacy-Systeme
X
- Gib Deinen Standort ein -
- or -