In den Köpfen vieler Beteiligter in einem Softwareprojekt hat sich die Meinung festgesetzt, Softwareänderungen seien etwas Schlechtes. Daraus entsteht dann oftmals die Forderung, das zu entwickelnde System "erweiterbar" und "konfigurierbar" zu machen, um Softwareänderungen vermeiden zu können. Was das konkret bedeutet wird in vielen Fällen jedoch offen gelassen, und so sieht sich der Entwickler mit der Frage konfrontiert: "Wie kann Erweiterbarkeit erreicht werden, bzw: Was bedeutet das überhaupt?".
Um eines vorweg zu nehmen: Diese Frage ist so komplex, dass es dafür keine Pauschalantwort gibt, gewissermaßen kein "Schema F". Einfacher ist jedoch die Frage, wie Erweiterbarkeit nicht erreicht werden kann; nämlich, indem Typisierung aus dem System entfernt wird. D.h. Es wird versucht, "Dinge" in seinem System so "generisch" wie möglich zu halten. "Generisch ist doch aber gut, oder?" In vielen Fällen schon, jedoch bedeutet generisch in diesem Fall "ungetypt". D.h. der Entwickler verzichtet absichtlich auf die technische Festlegung von bestimmten (notwendigen) Strukturen, während er sein System entwirft. Konkret kann das heißen, dass es keine klar definierten Gestalten bzw. Entitäten im System gibt, sondern lediglich irgendwelche Schlüssel/Wert-Beziehungen, oder Interfaces die eine Zeichenkette als Argument enthalten, welche dann ein XML oder CSV oder sonst etwas annehmen können. Es scheint dann fast so, als hätte man dadurch die gewünschte "Freiheit" erreicht. Doch ist dem tatsächlich so? In aller Regel gibt es eine klare Antwort darauf: Nein! Und zwar aus folgendem Grund: Ob man es wahrhaben will oder nicht, es gibt bestimmte Vereinbarungen in einem System.
Beispiel:
Verschiedenen Systemteile verlassen sich darauf, dass unter einem Schlüssel "MinValue" auch ein konkreter Wert vorhanden ist, ohne den z.B. ein bestimmter Algorithmus nicht funktionieren kann. D.h: Es existiert bereits eine Vereinbarung, nur dass diese Vereinbarung nicht direkt im Code ablesbar ist, sondern frei in irgenedwelchen Worddokumenten, Emails oder in den Köpfen der Beteiligten herumschwebt. Wird diese Vereinbarung geändert, so existiert zwar keine technische Repräsentation, die angepasst werden muss (weil man ja lediglich die Schlüssel/Wertepaare eingesetzt hat), jedoch müssen an allen anderen Stellen im System, für die die Semantik (also die Bedeutung) der Vereinbarung wichtig war, geändert werden. Das bedeutet, die Probleme haben sich nur verschoben, und gleichzeitig hat man verschiedene Nachteile in Kauf genommen: So gibt es z.B. keinen Kompiler, der die Vereinbarung / Konvention überprüfen kann; Fehler machen sich somit erst zur Laufzeit bemerkbar, das System wird also weniger robust. Darüber hinaus geht für die beteiligten Entwickler Kompfort verloren, da z.B. eine Entwicklungsumgebung keine Unterstützung mehr leisten kann.
Fazit:
-
Softwareänderungen werden nicht dadurch überflüssig, indem man so tut, als gäbe es keine Vereinbarungen und diese nicht in technischer Form ausdrückt.
-
Softwareänderungen bedeuten nicht das Ende der Welt, sondern sind in einem klar strukturierten System beherrschbar.
-
Hat man die Möglichkeit, Vereinbarungen in technischer Form auszudrücken, sollte man das auch tun. Oder anders ausgedrückt: Je expliziter, desto besser!