Herausforderung Brownfield, Teil 2: Das Sicherheitsnetz aufspannen

Seite 2: Versionskontrolle

Inhaltsverzeichnis

Ein weiteres Argument für auskommentierten Code wurde allerdings noch nicht ausreichend berücksichtigt, nämlich die Tatsache, dass man den Code möglicherweise später noch mal benötigt. Es mag durchaus vorkommen, dass nicht trivialer Code auskommentiert wurde. Ihn später zu reproduzieren mag mit viel Aufwand verbunden sein. Es erscheint in manchen Fällen tatsächlich sinnvoll, solche Codebereiche zu erhalten, da es letztlich nicht zu entscheiden ist, ob der Code überflüssig oder erhaltenswert ist. Als Sicherheitsnetz lässt sich jedoch ein anderes Werkzeug als das Auskommentieren verwendet, und zwar ein Versionskontrollsystem (VCS). Durch so ein System spielt es keine Rolle, ob man ältere Codebereiche noch mal benötigt oder nicht, da sie im System grundsätzlich zu Verfügung stehen, im aktuellen Stand der Codebasis aber nicht sichtbar sind und somit dort nicht verwirren.

Ein VCS hinterlegt alle Artefakte, die man zum Erstellen eines Programms benötigt. Dadurch ist zunächst sichergestellt, dass es eine zentrale Stelle gibt, an der sich alle benötigten Artefakte zusammengefasst finden lassen. Darüber hinaus sorgt ein VCS für eine Historie. Jede Übertragung von Artefakten in das System führt dort zu einer neuen Revision des Dokuments. Die unterschiedlichen Stände sind alle reproduzierbar, sodass sich auch Teile wiederherstellen lassen, die zu einem früheren Zeitpunkt aktuell waren. Somit ist es nicht mehr erforderlich, alte Stände durch Auskommentieren zu sichern.

Neben der Reproduzierbarkeit älterer Revisionen erhalten Entwickler durch ein VCS die Option, parallel an einer gemeinsamen Codebasis zu arbeiten. Sie können gleichzeitig Dateien aus dem VCS abrufen. Änderungen an den Dateien sind ohnehin kein Problem, solange nicht zwei Entwickler an derselben Datei Änderungen vornehmen. Selbst solche Fälle sind in der Praxis meist unkritisch, da moderne Systeme wie Subversion oder Git parallele Änderungen an derselben Datei zusammenführen können.

Richtig eingesetzt wirkt der Einsatz eines VCS auch einer anderen Angst entgegen, nämlich eine Datei, die zum Projekt gehört, verlieren zu können. Solange es keine zentrale Stelle gibt, in der alle zu einem Projekt gehörenden Dateien abgelegt sind, ist zu befürchten, dass Teams die Dateien über mehrere Stellen verteilen. Daraus resultiert die Angst, womöglich eine der Stellen zu übersehen. Die zentralisierte Dateiablage sorgt dafür, dass es unzweifelhaft genau einen Ort gibt, an dem alle Dateien abgelegt sind. Das erleichtert nebenbei die Datensicherung.

Der erste Schritt bei der Arbeit an einem Brownfield-Projekt muss demnach sein, alle relevanten Dateien unter Versionskontrolle zu stellen. Ferner müssen alle an Kunden herausgegebenen Versionsstände reproduzierbar sein. Das ist notwendig, damit der Quellcode einer beliebigen Version jederzeit auf Knopfdruck abrufbar ist. Nur so ist gewährleistet, dass der Releaseprozess nicht behindert wird. Ohne einfache Reproduzierbarkeit von Versionsständen droht die Gefahr, Fehler in unterschiedlichen Versionsständen nicht reproduzieren zu können – mit der Folge, dass der Kunde die Versionen nicht erhält. Das behindert jedoch eine schrittweise Verbesserung der Codebasis. Deshalb ist jede, an einen Kunden ausgegebene Version im VCS zu markieren. Durch ein geeignetes Schema der Versionsnummern ist erkennbar, um welches Build es sich handelt. Wird genau die Versionsnummer im System verwendet, um den entsprechenden Stand des Produkts zu markieren, lassen sich alle ausgelieferten Stände ohne Weiteres reproduzieren.

Erst dadurch ist es möglich, häufiger neue Versionen herauszugeben. Es sind nicht mehr Features zu sammeln, sondern es lassen sich auch Versionen mit nur einer kleinen neuen Funktion veröffentlichen. Sicherlich sollte man es nicht gleich übertreiben und zu viele unterschiedliche Versionen in Umlauf bringen, aber die Flexibilität, das technisch zu können, ist ein wichtiger Aspekt für die Weiterentwicklung und Veränderung eines Produkts. Man gewinnt dadurch die Flexibilität zurück, in kleinen Schritten neue Funktionen zu ergänzen beziehungsweise bestehende an geänderte Rahmenbedingungen anzupassen, ohne gleich gezwungen zu sein, den gesamten Kundenstamm auf eine neue Version zu bringen.