Woran Sie merken, dass Ihr Business Data Toolset (BDT) ein Refactoring braucht

Code Refactoring

SAPs BDT (Business Data Toolset) dient in jedem Financial Services Modul zur Erweiterung der Stammdaten um kundeneigene Felder, Tabellen und Prüfungen. Im Zuge der FS Modul-Einführung werden hier meist erste Kundenerweiterungen durchgeführt. Nach und nach werden dann in der Wartung und in Folgeprojekten neue Felder und Prüfungen hinzugefügt. Aufgrund der Komplexität des BDTs, mangelhafter Dokumentationen und unzureichender Entwickler Skill-Sets verfällt die kundeneigene BDT Codebasis zusehends. 

Die Folge sind nicht dokumentierte, unlesbare, schlecht wartbare und fehleranfällige BDT Entwicklungen die hohe Wartungskosten erzeugen. 

Es wird Zeit, über ein Refactoring mit anschließender Neuausrichtung der BDT Entwicklung nachzudenken.


Hier finden Sie 7 untrügliche Anzeichen, an denen Sie erkennen, dass  ein Refactoring Ihrer  BDT Entwicklung notwendig ist: 

  1. Eine Inflation BDT bezogener Entwicklungsobjekte 
    Einer BDT Anwendung liegt eine Funktionsgruppe zugrunde, die die Subscreens und Funktionsbausteine enthält. Werden hier mehrere Funktionsgruppen innerhalb einer Anwendung verwendet, ist dies ein sicheres Zeichen für den Verfall der BDT Anwendung. Eine Inflation von globalen Variablen im Top-Include ist ebenfalls ein Hinweis: im Top-Include sollten nur die einmal vorhandenen lokalen Gedächtnisse deklariert werden.

    Ebenfalls zu betrachten sind die Zeitpunkt-Funktionsbausteine der BDT Anwendung. Hier sollte pro BDT Anwendung nur ein Funktionsbaustein pro Event registriert sein. 

  2. “Wildwuchs" im BDT Customizing
    Wenn Sie schon gerade mit den  Zeitpunkt-Funktionsbausteinen beschäftigt sind, sollten Sie jetzt auch überprüfen,  dass Kundenfunktionsbausteine nur Kunden-BDT-Anwendungen zugeordnet sind.

    Tipp

    Tipp: Das ist noch leichter per Tabelle TBZ1F zu prüfen: Einfach Feld FNAME mit Y* oder Z* selektieren und dann in der Ergebnismenge Einträge in Feld APPLI ungleich Y* oder Z* finden.

    Suchen Sie weiterhin nach inaktiven Kunden-BDT-Anwendungen. Dauerhaft nicht genutzte Anwendungen sollten zurück gebaut werden. BDT Screen Layout Objekte (Feldgruppen, Sichten, Abschnitte, Bilder, Bildfolgen) ohne Zuordnung sollten ebenfalls entfernt werden. Durch den Verwendungsnachweis in den entsprechenden Objekten kann geprüft werden, ob das Objekt noch verwendet wird.

  3. Viele Entwickler und hohe Änderungsfrequenz 
    Wenn viele Entwickler unterschiedlichen Erfahrungsgrades an der BDT Anwendung sehr häufig Änderungen vornehmen, ist dies ebenfalls meist ein Hinweis auf entstehende Probleme im BDT. 

    Tipp

  4. Tipp: Mit Hilfe des SAP Custom Code Management (Teil des Solution Managers) kann man schnell die Entwicklungsobjekte identifizieren, an denen überdurchschnittlich viel und durch viele Entwickler geändert wird. 

  5. Mangelnde Modularisierung, keine Separation of Concern
    In BDT Funktionsbausteinen, die stets erweitert werden, entwickelt sich oft eine “Add-on” Kultur: Der Entwickler der seine Änderung hinzufügt, hängt sein Coding einfach an den existierenden Code an, um möglichst wenig “Impact” zu erzeugen. Bestehendes Coding, sei es noch so unverständlich, wird nicht reorganisiert. Der Funktionsbaustein wächst in seinen Lines-of-Code und wird in sich nicht mehr weiter modularisiert. Damit  wird er  unlesbar und unwartbar. Coding, dass fachlich nichts mit einander zu tun hat, steht im gleichen Kontext. Eine Trennung der Belange wird nicht erreicht. Sowohl die Trennung der Belange als auch die Limitierung der Lines-of-Code in Modularisierungseinheiten sind Anforderungen aus den offiziellen SAP Programmierrichtlinien. 

    Tipp
    Tipp: Um dieser Add-on Kultur entgegenzuwirken, hat es bewährt, erfahrenere Entwickler einen Code Review durchführen zu lassen, bevor Änderungen am BDT freigegeben werden.


  6. Unmengen toter und auskommentierter Code
    Eine hohe Änderungfrequenz bringt auch immer wieder eine Inflation von auskommentierten oder ungenutzten (toten) Code mit sich. Beides erschwert die Wartbarkeit und sollte abgestellt werden. Da die SAP Versionsverwaltung alle Änderungen an dem Entwicklungsobjekt dokumentiert, sollte das Auskommentieren von Code und das Kommentieren mit Änderungshinweisen (z.B. “Start Änderung 24.07.2015 User XYZ”) unterbleiben.

    Unbenutzte Variablen und Modularisierungeinheiten erschweren die Lesbarkeit und sollten daher immer entfernt werden. 

    Tipp

  7. Tipp: Die neue Eclipse basierte Entwicklungsumgebung unterstützt den Entwickler hervorragend dabei, vollautomatisch ungenutzte Variablen zu entfernen. 

     

  8. Eingriff in die Commit Steuerung des BDT 
    Die Verbuchung bei partizipierenden Anwendungen findet in der Tabellen besitzenden Anwendung statt, d.h. im Kundencoding dürfen keine Commit Anweisungen abgesetzt werden. 

  9. Die Funktionalität entspricht nicht den Anforderungen/Konzepten/Testfällen
    Das trifft nicht nur auf BDT Anwendungen zu, hat hier aber noch größere Bedeutung: Da Änderungen im BDT sowohl den Benutzerdialog als auch das Verhalten im Direct Input beeinflussen, ist eine aktuelle Dokumentation der Funktionalitäten unabdingbar. Wenn Testfälle auf alten Anforderungen basieren, kann ein Retest von BDT Funktionalität nur fehlschlagen und falsche Ergebnisse produzieren. 

Die hier beschriebenen Punkte treffen auf Ihr BDT zu? Dann ist Aufräumen des Codes und der BDT Objekte unausweichlich.

Folgendes ist dabei zu tun: 

  • Globale Variablen reduzieren
  • toten und auskommentierten Code löschen
  • unbenutzte BDT Layout Objekte löschen
  • Sinnvoll modularisieren
  • COMMITs entfernen und durch in UPDATE TASK Verbuchung ersetzen
  • Permanentes Aktualisieren von Konzepten / Dokumentationen / Testfällen
  • Code Ownership: Einige, wenige BDT erfahrene Entwickler warten alleine das BDT oder nehmen Änderungen von anderen per Code Review ab
  • BDT Know How bei Entwicklern durch Schulungen aufbauen 

Waren diese Infos für Sie hilfreich? Haben Sie weitere Anmerkungen zum Thema Refactoring? Oder haben Sie andere Erfahrungen mit Ihrem Business Data Toolset gemacht? Dann sprechen Sie mich an. Ich freue mich auf den Austausch.