7 Gründe für Quellcodeverwaltung bei der Microsoft Access Entwicklung

von Philipp Stiefel, ursprünglich veröffentlicht am 2. April 2016

Photo by Steve Richey used here under CC0 licensing

In diesem Artikel möchte ich die Gründe erläutern, warum ich ein Quellcodeverwaltungssystem verwende, wenn ich an Microsoft Access Projekten arbeite. Wenn du bereits über Quellcodeverwaltung Bescheid weißt, werden dir die meisten Gründe hier nicht neu sein. Dennoch könntest ein paar zusätzliche Einblicke in dieses Thema gewinnen, wenn du meine Sichtweise der Dinge liest.

Diese sieben Gründe sind absteigend vom wichtigsten zum am wenigsten wichtigen sortiert. – Das ist meine Meinung und du kannst sie für dich natürlich auch anders sortieren.

1. Versionshistorie

Quellcodeverwaltung zu verwenden erzeugt eine sprechende Historie deines Codes. Jede signifikante Änderung wird in deiner Quellcodeverwaltungshistorie protokolliert (natürlich nur, wenn du sie eincheckst/committest). Alle Quellcodeverwaltungssysteme ermöglichen es eine „commit message“ oder einen Kommentar zu einen Check-In hinzuzufügen. Bitte folge meinem Rat und nutze dies ausgiebig.

Wie deutlich die Historie zur dir spricht, hängt davon ab, wieviel Aufwand du in deine „commit message“ oder deine Kommentare steckst. Wenn du das möchtest und dein Quellcodeverwaltungssystem das unterstützt, kannst du jedes Mitglied deines Teams dazu zwingen einen aussagefähigen Kommentar oder sogar eine Verknüpfung zu einem Work Item oder einer Aufgabe in deiner Aufgabenverwaltung, zu erfassen.

Letztendlich liegt es bei dir, wieviel Aufwand du in jeden Check-In/Commit stecken möchtest. Ich persönlich bevorzuge dabei lieber zu viel als zu wenig. Ein paar Sekunden bei jedem Commit können deinem Team Stunden an Aufwand in der Zukunft ersparen. Wenn du nachvollziehen muss, wann und warum etwas in deinem Code von der einen Implementierung zu einer anderen geändert wurde und welche Dateien genau von dieser Änderung betroffen waren, wirst du die Zeit die du in deine „commit messages“ oder deine Kommentare gesteckt hast, tausendfach zurückgewinnen.

2. Einzelne Objekte/Dateien sind sofort vergleichbar

Ein Vorteil der aus den versionierten Dateien deines Projekts resultiert, ist die Möglichkeit ganz einfach verschiedene Versionen einer Datei miteinander zu vergleichen. Mit einem geeignetem DiffTool kannst du jeden Unterschied zwischen zwei Dateien visualisieren. Das ist extrem hilfreich, wenn du dabei bist einen Bug zu suchen, der in einer neuen Version deines Projekts gefunden wurden, aber in älteren Versionen noch nicht bestanden hat. Du bist dann in der Lage auch kleinste Änderungen zu erkennen, die anderweitig sehr schwer festzustellen gewesen wären und somit den die Ursache für einen Bug, wie den oben erwähnten zu finden. – Dieses Feature hat mit bereits unzählbar viele Stunden an Debugging erspart.

Manchmal kommst du vielleicht auch zu dem Schluss, dass die neuere Version einer Datei rettungslos verkorkst ist. Dann kannst du mit wenigen Mausklicks einfach eine vorige Version wiederherstellen.

3. Labeln oder taggen von Versionsständen

Quellcodeverwaltungssystem ermöglichen es dir, bestimmte Versionsstände deines Projekts zu labeln (oder taggen). Stell dir das vor, als würdest du einen Stapel Dokumente in einer bestimmten Fassung ausdrucken und mit einer Büroklammer zusammenheften.

Dies ist im Wesentlichen eine höhere Ebene der Organisation innerhalb deines Repositories. Jede einzelne Datei kann sehr viele Versionsstände haben. Von einer hohen Ebene betrachtet, ist eine einzelne Dateiversion nicht besonders relevant. Von Zeit zu Zeit möchtest du aber einen bestimmten Zustand deines Projektes, oder sogar mehrerer zusammengehöriger Projekte, markieren. Nun kannst du Labels oder Tags verwenden, um den Zustand einer beliebigen Anzahl von Dateien unter einem aussagefähigen Namen „zusammenzuheften“. Dies markiert dann einen signifikanten Milestone in deinem Projekt, oder z.B. eine Version die du an deine Kunden auslieferst.

Ok, natürlich kannst du das Gleiche erreichen, wenn du mit Access ohne Quellcodeverwaltung arbeitest und die komplette Datei bei jedem Milestone einfach in ein Archiv-Verzeichnis oder ein ZIP-Datei speicherst.

Der Vorteile eines Quellcodeverwaltungssystems ist der feingranulare Einblick den du gewinnst. Du kannst sehr einfach einzelne Dateien/Objekte eines bestimmten Versionsstandes ansehen und diese mit der gleichen Datei eines anderen Versionsstandes vergleichen. Genauso einfach bekommst du einen Überblick, was in einem Milestone alles enthalten war und du kannst einfach den kompletten Zustand einfach mit einen anderen Milestone vergleichen.

4. Der Quellcode ist überall verfügbar

Der Hauptgrund dafür, dass ich von etwa zehn Jahren von Visual SourceSafe zu Sourcegear Vault als Quellcodeverwaltungssystem gewechselt bin, war die Möglichkeit das Source Code Repository über das HTTP(S)-Protokoll erreichen zu können. Du kannst von überall auf der Welt auf deinen Quellcode zugreifen, vorausgesetzt du hast den notwendigen Client auf deinem Entwicklungsrechner installiert und das Quellcode Repository liegt auf einem Rechner, der über HTTP erreichbar ist.

Das hat mir sehr viel geholfen, als ich an einem Projekt gearbeitet habe, bei dem ein Teil der Arbeit direkt beim Kunden vor Ort erfolgte und ein anderer Teil der Arbeit aus meinem eigenen Büro. Kein nervtötendes und fehlerträchtiges hin- und her-kopieren von Versionsständen mehr. Ich konnte einfach die aktuelle Version des Codes aus dem Repository abrufen und mit einen schnellen Blick auf die Historie wusste ich unmittelbar wo ich am jeweils andern Standort mit der Arbeit aufgehört hatte, was ich geändert hatte und welche Dateien (Access Objekte) von diesen Änderungen betroffen waren.

Ich gebe zu, in den Zeiten von DropBox und OneDrive ist die einfache Verfügbarkeit des Quellcodes nicht mehr so besonders. Sie war es aber als ich damals angefangen habe mit Quellcodeverwaltung zu arbeiten. Selbst heute finde ich es weniger aufdringlich, dies explizit durch Check-In integriert zu haben, als entweder manuell die Datenbankdatei auf das OneDrive zu kopieren oder mir darüber Sorgen machen zu müssen, ob der Zustand der Datei konsistent ist, wenn er automatisch von OneDrive synchronisiert wird.

5. Koordinationssystem für mehrere Entwickler

Ohne Quellcodeverwaltung…

Wenn du mit mehreren Entwicklern an einem Projekt arbeitest, siehst du dich mit einem ernsten Problem konfrontiert. Wie hältst du die Entwicklungsarbeit von jedem einzelnen synchron? Es mag Projekte geben, in denen du die Zuständigkeitsbereiche der einzelnen Entwickler so weit von einander isolieren kannst, dass jeder wochenlang nur an seinen eigenen Dingen arbeitet und du alle Neuerungen an denen in dieser Zeit gearbeitet wurde, nur unmittelbar vor einen Release zusammenführen musst. – Aber vertraue mir, das wird jedes Mal ein gewaltiger PITA werden.

Jeder Entwickler muss einen recht genauen Überblick über alles haben, was er in der Zwischenzeit geändert hat. Egal wie ausgeklügelt das manuelle System ist, das du dir hierfür überlegst, es wird immer wieder Änderungen geben, die verloren gehen. – Verlass dich drauf.

Wenn du wirklich diesen Weg einschlagen willst, dann hoffe ich nur, dass du eine Menge automatisierter Tests mit einer hohen Codeabdeckung für dein Projekt hast. – Ach und denk daran, dass du ja auch die Änderungen an diesen Tests synchronisieren musst.

Ich habe in der Vergangenheit an mehreren großen Projekten auf diese Art mitgearbeitet. Ich möchte das nie wieder so machen. Niemals.

Mit Quellcodeverwaltung…

Wie ihr genau als Team mit Quellcodeverwaltung zusammenarbeitet, hängt von eurem System und eurem bevorzugtem Arbeitsstil ab. Aus diesem Grund werde ich hier nicht zu sehr ins Detail gehen.

Ihr habt ein zentrales Repository, das den verbindlichen Stand des Codes für euer Projekt enthält. Dies ist euer „Single point of truth“.

Du und jeder andere Entwickler in deinem Team kann sich den letzten Stand von dort abrufen. Es ist relativ einfach festzustellen, welche Dateien/Objekte im Repository geändert wurden. Du bist jederzeit in der Lage deinen lokalen Quellcode mit dem Stand im Repository zu vergleichen.

Die meisten SCC-Systeme kannst du so konfigurieren, dass sie Dateien sperren an denen du lokal arbeitest (Check out). Die anderen Mitglieder deines Teams können dann sehen, welche Dateien du ausgecheckt hast. Sobald du deine Änderungen eincheckst/committest, werden sie Teil des verbindlichen Projektstandes. Jeder andere Entwickler im Team kann deine Änderungen abrufen und einfach erkennen was genau du geändert hast.

Im Team an einem Projekt zu arbeiten wird immer Herausforderungen mit sich bringen und es wird immer etwas Overhead geben. Mach es dir nicht schwieriger als nötig; verwende eine Quellcodeverwaltung.

6. Prüfen von Code-Standard-Regeln, automatische Tests und mehr

Menschen sind faul, Entwickler ganz besonders. Das ist Teil des Jobs. Wir automatisieren Dinge, die sich wiederholen, wir mögen es nicht unnötigen Kram zu schreiben, wir optimieren was immer wir tun. Das sind gute Eigenschaften, aber manchmal behindern sie uns auch. Unser Gehirn optimiert geringfügige Details weg, die im Moment unnötig erscheinen. Wie zum Beispiel einen aussagefähigen Kommentar zu einem Check-In zu schreiben, oder wie die Tests auszuführen, die wie eigentlich vor jedem Commit/Check-In laufen lassen sollten. – Unser Code würde den Test doch eh bestehen, oder?

Ich muss gestehen: Schuldig im Sinne der Anklage. – Wir wissen es besser, aber dennoch nehmen wir immer wieder Abkürzungen und lassen Dinge weg, die wir tun sollten.

Daher bin ich froh darüber, dass ich Gültigkeitsregeln definieren kann, die immer geprüft werden, wenn ich Code einchecke. Das einfachste Beispiel dafür ist, den Kommentar zum Check-In als Pflicht zu definieren. Ich tue das bei allen meinen Projekten, egal wie geringfügig und unwichtig diese erscheinen mögen.

Du kannst es aber auch noch viel weiter treiben.

• Du könntest den eingecheckten Code gegen einen Satz von Coding-Standard-Richtlinien prüfen lassen.
• Du könntest automatisch dein Projekt nach jedem Check-In oder in definierten Intervallen kompilieren lassen. Wenn es mit den letzten Änderungen nicht mehr kompiliert, dann ist ganz sicher etwas nicht in Ordnung.
• Du könntest automatisch eine Reihe von Unit-Test mit deinem Projekt durchführen lassen.

Du hast eine Menge Optionen mit einem zentralen Code Repository, die du andernfalls nicht hättest. Zumindest nicht, wenn du in einem Team arbeitest.

7. Aktuelles Backup der einzelnen Objekte/Dateien

Jedes ernstzunehmende Versionsverwaltungssystem das in Microsoft Access integriert ist, wird einzelne Access Objekte (exportiert als Dateien) anstelle der ganzen, binären Access Datenbank verwalten. Wenn du dich in deinem Workflow an häufige Check-Ins hältst, wirst du automatisch einen zu jeder Zeit ein recht aktuelles Backup deines Codes haben.

Währende der Workflow für die Quellcodeverwaltung ein wenig zusätzlichen Aufwand bedeutet, bekommst du ein detailliertes, feingranulares Backup umsonst mitgeliefert, ohne dafür noch weiteren zusätzlichen Aufwand investieren zu müssen.

Wenn du dein Quellcode-Repository auf einem anderen Rechner als deiner lokalen Entwicklungsmaschine aufgesetzt hast, ist dieses Backup automatisch unabhängig von deinen lokalen Speichermedien. Also ein Totalverlust deines lokalen Computers, durch einen Festplattenschaden, Virusbefall, Diebstahl oder was auch immer bringt den eingecheckten Quellcode nicht in Gefahr.

Wenn es mir tatsächlich einmal passiert, dass meine lokale Arbeitskopie einer Datenbank korrumpiert wird und sich nicht mehr reparieren lässt, dann lösche ich sie einfach, rufe den letzten stand aus dem Repository ab und arbeite weiter. Gar kein großes Problem, sogar in diesem eher unangenehmen Szenario. – Wenn ich manuelle Backups meiner Datenbank hätte machen müssen, wäre das Backup höchstwahrscheinlich nicht so aktuell gewesen.

Der „Mehrere-Entwickler-Mythos“

Eine häufig vertretene Meinung ist, dass man eine Quellcodeverwaltung nur dann braucht, wenn man mit mehreren Entwicklern an einem Projekt arbeitet. – Hast auf die Reihenfolge oben geachtet? Für mich steht die Teamkoordination mehrerer Entwickler erst an fünfter Stelle.

Versteh mich nicht falsch. Wenn du in einem Team arbeitest, ist Quellcodeverwaltung absolut essenziell. Für mich gibt es keine Alternative, um in diesem Fall ohne Quellcodeverwaltung zu arbeiten. Aber ich arbeite auch an vielen Projekten als alleiniger Entwickler und selbst dann gibt es genügen absolut überzeugende Gründe mit Quellcodeverwaltung zu arbeiten. Ich sehe daher ein paar der oben genannten Gründe für mich als noch wichtiger an, weil sie auch dann ihrer Berechtigung haben, wenn man nicht im Team arbeitet.

Fazit

Quellcodeverwaltung ist ein unentbehrliches Werkzeug bei meiner Arbeit als professioneller Entwickler. Ich möchte nicht ohne arbeiten.

Wenn du bisher noch nicht irgendeine Form der Quellcodeverwaltung verwendest, dann hoffe ich, dass du einen guten Grund dafür hast. Andernfalls möchte ich dir dringend empfehlen, sie zu deinen Standardtools hinzuzufügen, die du bei jedem Projekt verwendest, das mehr als ein paar Tage dauert.

Offenlegung

Ich bin der Besitzer des kommerziellen Produktes Ivercy, einem Quellcodeverwaltungs-Add-In für Microsoft Access. Als Microsoft das eigene Quellcode-Add-In eingestellt hat, brauchte ich so dringend eine Alternative, dass ich selbst eine entwickelt habe.

Share this article: