Programmierrichtlinien und Namenskonventionen in der ABAP Entwicklung
Bei Quellcode ist es wichtig, diesen schnell verstehen zu können. Dies ist natürlich auch in der ABAP-Welt so. Wenn man als Entwickler in ein neues Projekt kommt, ist es wichtig sich schnell einzuarbeiten. Manchmal wird dies auf eine Probe gestellt, wenn in der Vergangenheit so gut wie keine Programmierrichtlinien bzw. Namenskonventionen verwendet wurden. Hier gibt es verschiedene Bereiche, wo Verständnisschwierigkeiten auftauchen könnten.
Einmal können sich Schwierigkeiten aus unvorteilhaften Strukturierung der verschiedenen Pakete ergeben und es sollten für eine gute Unterscheidung der Art von DDIC-Elementen oder Variablen im Quellcode Pre-, In- oder Suffixe verwendet werden.
Wofür sind Namenskonventionen noch wichtig?
Hier ist es wichtig, von vornherein grundlegende Programmierrichtlinien zu benutzen. So wird der Code im Unternehmen identisch und von jedem Entwickler schnell lesbar. Die mindsquare bietet Interessierten hier eine kompetente Lösung an. Hierzu wurden die besten Erkenntnisse aus jahrelanger Projekterfahrung zusammengetragen. Jedem unserer Mitarbeiter dient dies als Grundlage, die er so auch in Projekten einsetzen kann. Dies ist aber von Projekt zu Projekt unterschiedlich. Bei einigen gibt es leicht abweichende, bei einigen auch keine Programmierrichtlinien.
In einem meiner Projekte wurde beschlossen, bei zukünftigen Projekten die Paketstruktur anzupassen und einen Großteil der Elemente umzubenennen. Bisher waren die neueren Projekte immer eine Kopie des vorherigen Projektes. Dieses Konzept sollte nun einmal aktualisiert werden und danach weiter fortgeführt werden. Hier ergeben sich dann allerdings einige Herausforderungen. Zuerst wurde alle Bestandteile des Paketes auf nicht mehr verwendete Altlasten, wie DDIC-Elemente, Programme, Klassen etc. überprüft. Nachdem diese aussortiert waren, musste ein Großteil der DDIC-Elemente umbenannt werden, während hierbei alle Abhängigkeiten untereinander beachtet werden müssen.
So eine Umstellung ist mit manuellen Mitteln und Aufwand nicht zu bewerkstelligen. SAP bietet hierfür auch keinen Standard der in vollem Umfang DDIC-Elemente, deren Abhängigkeiten und die Paketzuordnung anpasst. Hier muss selber Hand angelegt werden und mehrere Funktionsbausteine in eine logische Reihenfolge zu bringen.
Die Abhängigkeiten der DDIC-Elemente sind vielfältig. Tabellentypen enthalten Strukturen, Strukturen enthalten wiederum Strukturen und Datenelemente, welche einer Domänen zugewiesen sind. Datenelemente werden wiederum in vielen Strukturen und Datenbanktabellen benutzt. Zudem kann noch ein Umhängen der Elemente zwecks weiterer Kapselung in neue Pakete erforderlich sein. Die folgende Abbildung verdeutlicht die Komplexität bei einer bereits kleinen Menge an Elementen.
Verwendung vs. Verwendungsnachweis, Abhängigkeiten der einzelnen DDIC-Elementen
Ein sinnvolles Vorgehen beim Umstellen oder Erneuern eines vorhandenen Projektes, kann somit sinnvoll in folgenden Ablauf gegliedert werden:
- Altlasten aufspüren – Kontrollieren aller vorhandener Elemente des Pakets auf noch aktive Verwendung
- DDIC-Elemente in einem Excelsheet auflisten Hier hat sich folgende Strukturierung als Vorteilhaft gezeigt:
DDIC-Elemente in Excel.
- Die Auflistung der unterschiedlichen DDIC-Typen sollte in folgender Reihenfolge erfolgen:
- Datenbanktabellen
- Tabellentypen
- Strukturen
- Datenelemente
- Domänen
- Kopieren aller DDIC-Elemente mittels Report, welcher den Excelsheet einliest
- Kontrolle der Elemente. Ob eine Stichprobe oder Gesamtkontrolle durchgeführt wird, muss jeder selber entscheiden
- Kopieren der Datenbanktabelleninhalte in die neu erstellten Datenbankkopien
- DDIC-Elemente im Code und z.B. WebDynpro-Komponenten aktualisieren
Die Erkenntnis aus meinen bisherigen Projekten ist daher eindeutig. Es ist enorm wichtig für die Übersichtlichkeit, Produktivität und Erweiterbarkeit, sich direkt zu Anfang eines Projektes konkrete Gedanken über Programmierrichtlinien, einen logischen Aufbau der Pakete und eine konstante Benennung der Elemente zu machen. Hier kann lieber mehr Zeit im Vorfeld in die Modellierung investiert werden, um später weniger Problemen gegenüber stehen zu müssen. Für diejenigen, die Programmierrichtlinien bisher noch nicht realisiert haben lohnt sich aber definitiv eine Anpassung, um auch für zukünftige Anforderungen gewappnet zu sein.
Die mindsquare Richtlinien für Namenskonventionen
Für eigene Projekte im Bereich SAP Entwicklung verwendet die mindsquare häufig eigene Richtlinien mit Namenskonventionen. Das Dokument stellen wir Ihnen gerne zur Verfügung.
Save as PDF
