ABAP Clean Code

Re: ABAP Clean Code

jocoder hat geschrieben: ↑

08.05.2019 12:53

Um Variablendreher, ungewollte Verschattungen usw. zu finden, verwenden wir schließlich Unit Tests.

Eigentlich erübrigt sich jede weitere Diskussion mit diesem Argument. Mit ordentlich implementierten Unit-Tests sollten keine Fehler, insbesondere dieser Art, auftauchen.

Re: ABAP Clean Code

SaskuAc hat geschrieben: ↑

08.05.2019 13:40

Eigentlich erübrigt sich jede weitere Diskussion mit diesem Argument. Mit ordentlich implementierten Unit-Tests sollten keine Fehler, insbesondere dieser Art, auftauchen.

Irgend etwas an dieser Art Aussage kommt mir bekannt vor.

Re: ABAP Clean Code

Also, zunächst einmal hat eine Variable in einer Routine einen bestimmten Kontext. Ich habe also eine Methode (oder Form-Routine), die zu einer LIFNR einen Namen ermittelt. Das brauche ich für den Rechnungsempfänger und den Warenempfänger. Dann sehen die Aufrufe so aus:

name_warenempf = get_name_from_lifnr( lifnr_warenemfp ).

name_rgempf = get_name_from_lifnr( lifnr_rgemfp ).

In der Methode heißt das Feld dann immer LIFNR.

Zweitens: In einer Unterroutine spricht man keine globalen Felder an. Das macht die Kapselung kaputt. Insofern ist die Verschattung richtig und gut, weil man nicht versehentlich die globalen Variablen anspricht.

Ich arbeite sehr gern mit me-> bzw. Klassennamen vor der Variable, wenn ich die der Klasse meine. Das "Umbenennen" mache ich per Suchen/Ersetzen binnen Sekunden (kommt auch so oft gar nicht vor).

Ganz ehrlich: Ich habe noch nie ein Problem gesehen, das durch HN gelöst werden würde. Per Mouseover kann ich jederzeit zu jedem Datenobjekt mehr Infos abrufen als ich in ein Präfix stecken kann.


Ralf

Re: ABAP Clean Code

Die Namen sollen nur strukturell zeigen, was ich meinte. Dass die Feldnamen selbst Mist sind, ist klar, mir ist auf die Schnelle nichts Besseres eingefallen.

Mir ging es darum, dass die Aufrufer (weil sie einen anderen Kontext haben) unterschiedliche Feldnamen verwenden. Auch unterschiedlich zur eigentlichen Methode.


Ralf

Re: ABAP Clean Code

Es gibt einen erheblichen Unterschied zwischen der Komplexität im Abschnitt "Assembler" und dem letzten Absatz deines Beitrages.

Assembler brachte eine Komplexität mit sich, war also in sich komplex. Das führte zu vereinfachten Hochsprachen (die dann den Nachteil haben, dass z. B. mit Speicherplatz geradezu verschwenderisch umgegangen wird -- wenn man sich überlegt, was auf einem AMIGA alles schon ging an grafischer Komplexität....).

Inzwischen haben wir eine einfache Sprache (ABAP zu lernen, ist nun wirklich nicht schwierig), aber die umgesetzten Geschäftsprozesse sind zum Teil endlos kompliziert, die Zahl der Buchungen wächst ins Unermessliche. Aus beiden Gründen wäre es völlig illusorisch, einen SAP-Kunden "von Hand" auf T-Konten zu buchen.

Nun sind viele dieser Tätigkeiten aber (abstrakt betrachtet) einer gewissen Ähnlichkeit unterworfen. Praktisch jede DB-Selektion endet in einem SELECT und der hat immer denselben schematischen Aufbau. Was also liegt näher als ein (!) generischer SELECT, der von allen verwendet wird? So haben wir das und als es darum ging, Cluster-Tabellen zu integrieren, haben wir das tief in der Persistenzschicht gemacht, damit den Aufrufer gar nicht interessieren muss, ob die Daten aus einem Cluster kommen oder aus einer transparenten Tabelle. Der sagt (schematisch gesehen) nur
Und wenn ich das so zentral verbastele kann ich eben auch eine Funktion dazubasteln, die eine zweite DB-Verbindung aufmacht, die inzwischen recht intensiv verwendet wird.

Natürlich ist eine polymorphe Methode an sich schwierig lesbar, weil sie erst aus ihrem Kontext heraus "rund" ist (darum ist die Doku so wichtig). Aber ich kann eben sehr komplexe Zusammenhänge auf ihren kleinsten gemeinsamen Nenner herunterbrechen und sie gleich behandeln. Und sobald man etwas herunterbricht, wird die Formulierung abstrakt. Das weiß jeder, der öfters mal Gesetze liest oder Beipackzettel.

Es klingt auch schräg, wenn man in einer Methode erstmal feststellen muss, was für Importing-Parameter man überhaupt hat. In meinen SBAL-Logger kann man alles reinwerfen. log->add( xxx ), wobei xxx (type any) eine Message sein kann, ein BAPIRET oder BAPIRET2 als Struktur oder Tabelle, eine Ausnahme (die ggf. weitere Ausnahmen enthalten kann), etc. Es kommt immer korrekt ins Log, weil ich über RTTI identifiziere, was hab ich denn und fallweise sage "ein Feld vom Typ symsgid kommt im Log immer DA hin". Der Aufrufer hat *irgendeine* Meldung, die er ins Log schreiben will, die kippt der da rein und muss sich um nichts kümmern. Das führt natürlich zu einer gewissen Komplexität in meiner Methode, aber die habe ich nur einmal.

Jetzt der obligatorische Auto-Vergleich: Heutige Autos sind viel einfacher zu fahren als frühere -- das bezahlt man mit dem Preis, dass die Autos selbst viel komplexer sind. Man kann die Komplexität nur verschieben, nicht wegmachen. Aber da passt dann das Konzept der versteckten Implementierung ganz gut: Ich löse ein komplexes Problem, verpasse ihm eine gescheite Schnittstelle und eine Dokumentation und schon muss es mich (in der Regel) gar nicht mehr interessieren, wie dieses Problem gelöst wird. Ich muss nicht wissen, wie der Anlasser funktioniert, um ihn oder ein anderes Teil zu tauschen. Ich weiß, wo der Anlasser ist, wie er angeschlossen wird und wie er sich verhalten sollte, wenn er korrekt arbeitet. Wie er funktioniert, muss ich nur wissen, wenn ich den Anlasser selbst reparieren will.


Ralf

Re: ABAP Clean Code

DeathAndPain hat geschrieben: ↑

20.05.2019 13:02

Dann hast Du unterschiedliche Aufrufstellen. Ein SELECT ist ein Befehl. Ein Aufruf des gemeinsamen SELECTs ist ein Befehl. Du ersetzt also einen Befehl durch einen anderen, spart nichts, fügst aber eine Abstraktionsschicht hinzu, die die Sache unübersichtlicher macht. Da haste nichts gewonnen.

Ich weiß, dass du kein Freund davon bist - ich habe die Vorteile einer einheitlichen Persistenzschicht kennengelernt und wurde davon überzeugt. Einen Vorteil habe ich genannt: Im Grunde interessiert mich das Medium nicht, auf dem Daten gespeichert sind, wenn ich auf Ebene der Geschäftsobjekte hantiere.


Ralf

Re: ABAP Clean Code

Das ist falsch - hast du eine Clustertabelle, stehst du da mit deinem SELECT. Um mal nur *ein* Beispiel zu bringen.



Ralf

Re: ABAP Clean Code

Ja, du hast vollkommen recht, die Persistenzschicht bietet auch diese Möglichkeit.

Aber die Möglichkeit zum Mocking entsteht durch die Kapselung, nicht durch die Persistenzschicht (die zwar auch kapselt, aber in erster Linie abstrahiert). Sprich: Durch das Verschieben eines SELECT in eine Methode erhalte ich die Möglichkeit, ein Mocking zu implementieren. Das ist dann überhaupt nicht mehr abstrakt (und das Mehr an Abstraktion scheint ihn ja zu stören).

Das erhalte ich auch durch die Persistenzschicht, aber eher als Nebeneffekt. Der eigentliche Zweck ist es, eine einheitliche Schnittstelle (ZIF_PERSISTABLE oder so) zu implementieren, die jegliche Form der persistenten Datenspeicherung vereinheitlicht. Im Grunde genommen könnte ich auf diese Art und Weise sogar eine Datei auf einen Applikationsserver speichern mit derselben Anweisung, mit der ich Daten in eine Tabelle schreibe (die Parameter unterscheiden sich freilich und die ganze Implementierung).

Und auch wenn er immer wieder behauptet, einem SELECT sei egal, ob ein konventionelles oder ein HANA-System angesprochen wird, wird das auch durch Wiederholung nicht richtiger. Wer sowas sagt, der hat sich die Dokumentationen und Anleitungen der SAP zu HANA noch nicht angesehen.


Ralf