Quellcodeverwaltung – warum eigentlich?

Ich habe zweifellos bereits sehr viel über Quellcodeverwaltung geschrieben, so dass langsam auch die Gefahr besteht, dass ich anfange, mich zu wiederholen. Doch ich glaube, über die Frage, warum ich das eigentlich mache, habe ich mich noch nicht besonders intensiv ausgelassen. Das will ich jetzt mal nachholen.

Gedanken

Es ist viele Jahre her, als ich einen Kollegen fragte, ob er Quellcodeverwaltung verwende. Er hatte gerade erläutert, wie er die verschiedenen Versionen seiner Software auf seiner Festplatte verwaltet. Immer wenn eine Version fertig sei und die weiteren Arbeiten anstünden, würde er das komplette Verzeichnis duplizieren, an das neue eine Versionsnummer anhängen und dann darin weiter arbeiten. Meine Frage quittierte er folglich auch mit einem verständnislosen Blick und einem Fingerzeig in Richtung der Folie mit dem Verzeichnisbaum. Wie gesagt, es ist viele Jahre her, und der Kollege soll ungenannt bleiben, ich will ja niemanden bloßstellen. Vielleicht war es ja auch eine Kollegin, gendern muss sein.

Im Grunde war die Idee natürlich keineswegs dumm. Auf diese Weise wurde sicher gestellt, dass bei nachträglichen Änderungen z.B. an Version 1.0 diese immer noch unverändert zur Verfügung steht. Und alle anderen Versionen ebenfalls, zur Not auf einer externen Datensicherung. Letztlich macht ein Versionskontrollsystem das vom Prinzip her ähnlich, nur nicht unbedingt mittels Verzeichnissen.

Warum soll ich alte Versionen aufheben?

Das ist natürlich eine gute Frage. Welchen Zweck hat es, Version 1.0 aufzuheben, wenn ich inzwischen längst bei 7.4.2 bin, außer aus sentimentalen Gründen? Aus meiner Sicht gibt es durchaus Gründe.

Einerseits könnte es sein, dass manche Anwender einfach keine Lust haben, dauernd ein Update einzuspielen. In manchen Projekten dürfen sie es auch nicht, weil die Umgebung, in der die Software eingesetzt wird, in einer Weise kontrolliert wird, dass wilde Updates schlicht zu viel Aufwand bedeuten würden: Komplette Tests, Validierung, staatlich überwachte Abnahme, wie auch immer man das nennen mag. Dann ist es wichtig, von der alten Version ausgehend nur wenige Änderungen zu machen und diese genau zu dokumentieren. Aber wie kann ich sicherstellen, den richtigen Quellcode zu finden?

Es könnte sein, dass eine Funktion (vielleicht eine Berechnung?) früher mal auf eine bestimmte Weise gemacht werden musste. Diese mag sich dann im Laufe der Zeit geändert haben, aber dann muss ich nachweisen, dass sie früher auch wirklich korrekt gemacht wurde. Wie soll das gehen?

Vielleicht habe ich auch an einer Stelle etwas verändert, das sich einige Versionen später als fehlerhaft herausstellt. Nun fällt es in v7.4.2 auf, aber es ist ein so gravierender Fehler, dass alle Anwender unbedingt ein Update erhalten sollten. Ich weiß, dass einige ältere Versionen noch verwendet werden, aber wie kann ich nun herausfinden, in welcher Version genau der Fehler reingekommen ist?

Manchmal muss ich bei jedem Release eine Liste mit Dingen beifügen, die ich geändert oder neu gemacht habe, oder wo Bugs behoben wurden. Woher soll ich denn nach mehrmonatiger Arbeit noch wissen, was ich alles gemacht habe? Und von meinem Kollegen weiß ich das ohnehin nicht!

Oder der Chef will wissen, warum denn um Gottes Willen dieser Bug noch nie aufgetaucht ist? Habt ihr nicht richtig getestet (Chef, hast du das Budget für die Tests eigentlich schon freigegeben?), oder arbeiten die User nicht richtig mit der Software? Seit wann soll das denn angeblich schon so sein?

Ihr könnt es euch denken: Die Antwort auf alle diese Fragen ist nicht 42, sondern “Quellcodeverwaltung”. Das muss nicht Git sein, aber ich will die Beispiele in diesem Artikel trotzdem auf Git aufbauen. Abgesehen von der Frage “zentral vs. dezentral” sind die grundlegenden Unterschiede der Systeme gar nicht so groß.

Ein Leben ohne Quellcodeverwaltung ist möglich, aber sinnlos

Dieses Zitat von Bernd Gilles aus dem Vortrag Quellcodeverwaltungen – Weltmarktübersicht geht natürlich auf Loriot zurück, wobei jener wohl bei Nietzsche gespickt hat. Keiner der beiden hat sich über Quellcodeverwaltung geäußert, aber gültig ist der Spruch dennoch. Das Warum haben wir geklärt, jetzt geht es um das Wie.

Eine sicherlich triviale Voraussetzung dafür, später noch auf Aufzeichnungen zurückgreifen zu können, ist die, dass man sie (die Aufzeichnungen) machen muss. Gerade an dieser Stelle wird oft eingeworfen, dass das ja unnötig viel Zeit kostet. Aber ich empfinde das ganz anders. Es ist natürlich richtig, dass man schon ein paar Minuten am Tag dafür opfern muss. Aber so schlimm ist es dann auch nicht.

Im Gegenteil: Seit ich mir angewöhnt habe, kleinschrittig zu committen, denke ich nach jedem Schritt nochmal darüber nach, was ich getan habe, wie ich es getan habe, und warum ich es getan habe. Wenn es im ALM einen Eintrag dafür gibt, ist das auch sehr hilfreich.

Das kleinschrittige Committen sorgt dafür, dass meine Commits übersichtlich bleiben. Wenn ich später mal auf diesen Commit aufmerksam werde (z.B. durch einen Bisect), werde ich schnell überblicken, was hier eigentlich passiert ist.

Die Frage nach dem Wie hilft mir, die Commit-Message vernünftig zu schreiben. Das ist eine verbale Beschreibung meiner Arbeit. Auch das erleichtert das zuvor gesagte.

Und das Warum wird einfach durch eine Referenz auf die Bug-Nummer des ALM-Tools beantwortet. Dort steht nämlich quasi der Arbeitsauftrag, also ein Requirement, ein nachträglicher Feature-Request oder eine Bug-Meldung eines Users oder Testers.

Das alles zusammen, also den Code und die Beschreibung, wird zusammen mit dem aktuellen Datum und der Uhrzeit sowie meinem Benutzernamen dem Versionskontrollsystem anvertraut. Manchmal (je nach System) erhält auch das ALM-System darüber eine Mitteilung, so dass mein Commit (Changeset, Revision, …) dort im Gegenzug ebenfalls verlinkt wird. Nun kann von beiden Seiten die jeweils andere Seite schnell aufgefunden werden.

“Sehr übersichtlich.” – Loriot.

Ja, und damit sind wir auch fast schon wieder am Ende des Themas. Fassen wir zusammen: Quellcodeverwaltung ist …

  • nützlich
  • notwendig
  • einfach
  • nicht sehr zeitaufwändig
  • ein Hilfsmittel für sorgfältiges Programmieren

Wenn euch noch etwas dazu einfällt, die Kommentare sind offen :-)

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

15 + acht =