Qualitätsmanagement in der ABAP-Entwicklung unter SAP

2.1 Übersichtlicher und verständlicher Source Code

Bei größeren Projekten empfiehlt es sich, den Source Code übersichtlich und verständlich zu gestalten. In der folgenden Liste möchte ich Ihnen daher einige einfache Gestaltungsrichtlinien vorstellen, die dazu beitragen:

1. Prozeduren kurz halten:

• Nicht mehr als 60 Zeilen gibt z.B. das Open-Source-Projekt https://github.com/sbcgua/mockup_loader an,
• Makros sollten nicht mehr als fünf Zeilen umfassen, ist meine Empfehlung (die Variablennamen &1, &2, &3 ... lassen längere Makros schnell unübersichtlich wirken).

2. Aussagekräftige Programm-, Klassen-, Methoden-, Prozedur- und Parameternamen vergeben:

• oft verwendete Abkürzungen dokumentieren,
• einheitliche Begriffe und Abkürzungen verwenden, die dem gesamten Team geläufig sind.

Aussagekräftige Namen und auch Kommentare sollen die Implementierung so detailliert beschreiben, dass sie von jedem Entwickler verstanden werden kann. Wofür wurde unser Programm konzipiert? Welchen Zweck erfüllt diese Prozedur? Mit welchen Werten sind die Eingabeparameter zu übergeben? Unter welchen Umständen werden änderbare Parameter (CHANGING) abgewandelt? Unter welchen Umständen werden Ausnahmen oder Fehlermeldungen geworfen? Die entsprechenden Antworten sollten wir den Namen bzw. Kommentaren entnehmen können.

Innerhalb von Prozeduren können Sie mit freiformulierten Kommentaren den Zweck Ihrer Anweisungen ausdrücken. Nach außen können Sie die für die Verwendung der Prozedur relevanten Informationen als ABAP-Doc-Kommentare bereitstellen. Listing 2.1 zeigt die Platzierung eines ABAP-Doc-Kommentars vor der entsprechenden Methodendefinition.

"! Liest alle Positionen (abgesagte und
	"! nicht abgesagte Angebote).
	"! @parameter angebots_nummern | Positionen dieser 
	"! Angebote werden gelesen 
	"! @parameter positionen | alle Strukturfelder 
	"! werden mit den Werten aus der Tabelle vbap 
	"! uebergeben
	 
	METHODS get_angebotspositionen 
	  IMPORTING
	    angebots_nummern TYPE zangebots_kopfdaten
	  EXPORTING
	     positionen TYPE zangebots_positionen.
	

Listing 2.1: Beschreibung einer Methode mit ABAP-Doc-Kommentaren

Auf die Syntax der ABAP-Doc-Kommentare gehe ich nochmal detailliert in Abschnitt 3.3 ein.

Die verwendeten Namen sollten einer eindeutigen Terminologie folgen. Sie sollten sie daher sinnvollerweise mit den Prozesseigentümern und den Entwicklern abstimmen, damit die Terminologie in einem klaren Zusammenhang mit dem im Code abgebildeten Geschäftsprozess steht. APIs bzw. Bibliotheken, die technischer Natur sind (z.B. die RTTS[RunTime Type Services]-Klasse cl_abap_typedescr), können mit technischen Fachbegriffen beschrieben werden. Bei anwendungsspezifischen Quelltexten ist die Verwendung von Fachbegriffen, die dem Geschäftsprozess entlehnt wurden, oft aussagekräftiger als eine rein auf die technische Umsetzung fokussierte Terminologie.

3. Versionsverwaltungswerkzeuge richtig nutzen:

Änderungshinweise mit Autor und Datum in den einzelnen Zeilen erschweren nach vielen Modifikationen die Lesbarkeit und Verständlichkeit. Versionsverwaltungswerkzeuge dokumentieren bereits alle Änderungen mit Autor, Datum und den eingefügten, geänderten sowie gelöschten Zeilen.

• Das Versionsverwaltungswerkzeug der ABAP Workbench ist, wie in Abbildung 2.1 ersichtlich, über den Menüpfad Hilfsmittel • Versionen • Versionsverwaltung zu erreichen. Bei der Freigabe eines Transportauftrages wird automatisch eine neue Version erzeugt. Die älteren Versionen gehen nicht verloren, wenn Sie auf Änderungshinweise im Code verzichten.
• Inzwischen gibt es auch Open-Source-Versionsverwaltungswerkzeuge wie git® (https://git-scm.com) und abapGit (https://github.com/larshp/abapgit), die Änderungen im Source Code optimal nachvollziehbar machen. Beide Werkzeuge stelle ich in Abschnitt 6.1 detailliert vor.

Abbildung 2.1: Versionsverwaltung in der ABAP Workbench