Seite 4: Fazit

Inhaltsverzeichnis

Open-Source als Beispiel für Versionierung

Viele große Softwareprojekte nutzen Open-Source-Frameworks als Grundlage für ihre Entwicklungsarbeiten. Da auch Frameworks dem Wandel unterzogen sind, ist bei jeder neuen Version zu überlegen, ob ein Upgrade sinnvoll ist. Sollten sich beispielsweise die Anforderungen geändert haben und es lässt sich dem mit einem Umstieg nachkommen, ist der Wechsel auf die neue Version durchaus sinnvoll.

Das funktioniert allerdings nur dann reibungslos, wenn die Weiterentwicklung des Open-Source-Frameworks rückwärtskompatibel ist. In dem Fall ist sie nach dem Liskovschen Prinzip austauschbar. Da das nicht immer der Fall ist, hat sich im Laufe der Jahre ein Versionierungsschema durchgesetzt, bei dem der Sprung auf eine neue Hauptversionsnummer (Major Version) meist inkompatible Änderungen enthält. Projekte, die auf solchen Frameworks aufbauen, können frei entscheiden, ob sie die Umstellungen aufgrund der neuen Funktionen mitmachen wollen oder ob sie mit älteren Versionen inklusive einiger Fehlerkorrekturen leben können, sollten die alten Versionen nicht länger unterstützt werden.

Fazit

Die Softwareentwicklung geht langsam, aber beständig den Weg, den auch die Automobilindustrie eingeschlagen hat. Wie beim Autobau existieren in Softwareprojekten vorgefertigte Bauteile, siehe Open Source, die in neuen Systemen verwendet werden können und zum Teil austauschbar sind. Das Liskovsche Substitutionsprinzip ist nur ein mögliches Konzept, um Modularisierung zu erreichen. In der ersten Version sind die Vorteile meist nicht sichtbar, unmittelbar danach kann das eigene System allerdings viel schneller weiterentwickelt werden.

Ulf Fildebrandt
arbeitet für SAP seit 1998 in verschiedenen Bereichen als Development Architect. Während der letzten Jahre war er verantwortlich für Produkte im SOA Umfeld der SAP AG.

Links & Literatur

1. SOLID
2. Robert C. Martin; Agile Software Development. Principles, Patterns, and Practices; Pearson Education, 2002

(jul)