„Wie war das nochmal?“ – Geschickte Inline-Versionierung
Sei es fremdes Coding, das schon Jahrzehnte alt ist, oder das eigene von vor wenigen Wochen: Als Entwickler fragt man sich oft: "Wie war das nochmal?". Es ist ganz normal: Mit der Zeit wachsen Programme. Es gibt neue bzw. geänderte Anforderungen oder beispielsweise Bugfixes, nachdem das Programm schon lange produktiv gelaufen ist und deren Notwendigkeit in der Testphase nicht bemerkt wurde.
Repariert oder erweitert ist meist schnell; was ist aber, wenn danach eventuell doch wieder zurückgerudert werden soll? Klar, der SAP-Standard bietet eine Versionsverwaltung. Diese bietet neben dem Logging, wer wann geändert hat auch die Möglichkeit, jede Version im Splitscreen-Editor vergleichen zu können. Somit können Änderungen gut nachvollzogen werden. Zu beachten ist, dass für jede vorhandene Version eine „Version gezogen werden muss“. Das geschieht entweder manuell, oder automatisch, wenn ein Transport, der das Objekt beinhaltet freigegeben wird.
Während des Entwickelns ist dieses Art der Versionierung aber nicht immer praktisch. Man verlässt dafür das Coding, vergleicht im Splitscreen, merkt sich die Zeilennummer, geht zurück,… . Wäre es nicht geschickter, IM CODE auf einen Blick zu sehen, wo welche Änderungen stattgefunden haben? Mittels geschickter Inline-Versionierung lässt sich das umsetzen.
Inline-Versionierung umsetzen
Dazu ist eine „Einheit“ zu wählen, nach der man versionieren möchte. Es bieten sich z.B. Transportaufträge oder Change-Request-Nummern an. Ein Datum ist weniger geeignet, da sich Entwicklungen meist über die Länge eines Tages erstrecken. PRO DATEI (Report, Include,…) wird eine Historie angelegt. Das geschieht gleich beim ersten Anlegen des Files, nicht erst bei der ersten Änderung! Diese Historie wird manuell durch den Entwickler erweitert, sobald er das Objekt berührt und Änderungen vornimmt. Er notiert seine Nutzerkennung, das Datum an dem die Änderung begonnen wurde, die oben erwähnte „Einheit“ (hier TA-Nummer) und eine kurze Zusammenfassung, was getan wurde. Wurde in einer Einheit, sprich hier in einem Transportauftrag inhaltlich mehrere Dinge umgesetzt, werden diese optisch getrennt eingetragen. Die folgenden Bilder zeigen beispielhaft, wie die Historie wächst.
Und nun zum eigentlichen Clou: Alle Änderungen im eigentlichen Coding werden unter Angabe der „Einheit“ inline dokumentiert. Wird eine Zeile geändert, wird ein Kommentar am Ende der Zeile eingefügt. Erstreckt sich die Änderung über mehrere Zeilen, ist der entsprechende Block mit Kommentaren zu umranden. Dabei wird unterschieden zwischen Einfügen, Ändern und Löschen: „+…“, „~…“, „-…“. Hinweis: Löschen wird durch auskommentieren realisiert.
Das ist effizient während des Programmierens, da keine Erklärung, kein Datum oder sonstiges getippt werden muss. Die schnellkopierte Einheit samt Änderungsart dient als Referenz zur Historie, welche näheren Aufschluss gibt. Wenn der Entwickler eine Änderung, die er in der Historie entdeckt hat, nachvollziehen möchte, kann er auch unter Zuhilfenahme der Suchfunktion mittels der „Einheit“ komfortabel an die relevanten Stellen gelangen. Splitscreen, adé!
Wichtig für den Einsatz dieser Technik: Es genügt selbstverständlich nicht, wenn eine Person so programmiert. Die konsequente Verwendung ist als Arbeitsanweisung (unternehmensweit, oder zumindest für alle Entwickler, die die gleichen Objekte anfassen) zu etablieren und im Optimalfall auch durch eine Qualitätssicherung zu prüfen.
Die Inline-Versionierung ist ein simples Prinzip, welches das Programmieren enorm erleichtert. Besonders wenn viele (womöglich sogar externe) Entwickler in einem Unternehmen tätig sind, ist eine Technik wie diese zu empfehlen.
Nutzen Sie Ähnliches in Ihrem Unternehmen? Wie lösen Sie das Problem?