Moderne Entwicklungsprozesse bei SAPlern
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
das ist sicherlich bereits mehr als nur ein mal passiert. Aber wie das mit Religionen ist, so verhält es auch mit Programmierrichtlinien...ralf.wenzel hat geschrieben: Man sollte sich mal zusammensetzen und sowas wie ein "Handbuch für gutes Coding" schreiben - aber dazu müssten sich genug Leute erstmal einig werdenDie SAP lässt "uns" mit dem Thema ja allein.
neulich wurde hier ein Link zu einem DSAG-Leitfaden für Entwickler gepostet, als eine der Empfehlungen wird man dort Präfixe als Vorschläge für Namenskonventionen finden. So ganz aus der Welt scheint diese Vorgehensweise also nicht zu sein:
https://www.dsag.de/de/ueber-dsag/press ... licht.html
Folgende Benutzer bedankten sich beim Autor Alexander D. für den Beitrag:
Unit605
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Der Ton macht die Musik. Ich weiss, das trifft bei Dir auf taube Ohren.ralf.wenzel hat geschrieben:So ist das mit Meinungen: Wenn ich eine Meinung habe, halte ich die für richtig und sag das auch. Wenn ich nicht weiß, ob etwas richtig ist oder nicht, hab ich noch keine Meinung dazu.Unit605 hat geschrieben:Bei Deinem Diskussionstil habe ich persoenlich immer das Gefuehl, dass nur das gilt und richtig ist, was Du fuer gueltig und richtig haelst..
Wenn ich aber eine Meinung habe, heißt das nicht, dass ich mich nicht von einer anderen überzeugen lasse. Das passiert oft genug.
Also kannst Du Deine Tabelle auch einfach alle durchnummerieren oder LT_EKKO_NORM und LT_EKKO_UMLAG nennen.ralf.wenzel hat geschrieben: Doppelklick drauf und du weißt es
Also, dass ich mein Programm anderen erklaeren musste, kam wohl in den seltesten Faellen vor.ralf.wenzel hat geschrieben: Du erklärst doch nicht DIR dein Programm, sondern anderen! Abgesehen davon ist (ich wiederhole mich) die viel schwieriger zu ermittelnde Frage die, was ist denn da nun drin? Klar, EKKO-Daten. Bestellungen? Anfragen? Angebote? Um das zu ermitteln, muss ich mich durchs Coding wühlen.
Wenn ich allerdings, anderen Entwicklern mal ein Programm erklaert habe, dann ist ja wohl eindeutig einfacher, wenn ich meine Program "inn- und auswendig" kenne und nicht auf alles ein Doppelklick machen muss.
Also ich bevorzuge lt_ekko_bestellungen, lt_ekko_anfragen oder lt_ekko_angebote als tabelle1, tabelle2, tabelle3 im Programm.
Aber Du hast recht, ich erklaere mir nicht meine Programme, das es nicht noetig ist. Ich lese meine Programme "wie ein Buch".
Dickes Danke fuer den Link.Alexander D. hat geschrieben: das ist sicherlich bereits mehr als nur ein mal passiert. Aber wie das mit Religionen ist, so verhält es auch mit Programmierrichtlinien...
neulich wurde hier ein Link zu einem DSAG-Leitfaden für Entwickler gepostet, als eine der Empfehlungen wird man dort Präfixe als Vorschläge für Namenskonventionen finden. So ganz aus der Welt scheint diese Vorgehensweise also nicht zu sein:
https://www.dsag.de/de/ueber-dsag/press ... licht.html
Widerspricht sich zwar mit:
... finde es trotzdem sehr gut.Ein Bekannter von mir, der u. a. bei der SAP in der Entwicklungsabteilung gearbeitet hat, meinte dazu, dass sowas nur Leute machen, die nicht programmieren können.
DAS ist meiner Meinung nach eines der "heiligsten Ziele" der Programmierung. Ich bemühe mich auch, das so hinzubekommen (klar umrissende Aufgaben von Klassen/Methoden oder auch FORMs, aussagekräftige Namen, wobei hier manchmal auch einfach die technischen Namen à la EKKO sinnvoll sein können). Dann benötigt man auch keine Vorschriften im Code Inspector, wieviele Kommtarzeilen anteilig zu vergeben sindUnit605 hat geschrieben:Aber Du hast recht, ich erklaere mir nicht meine Programme, das es nicht noetig ist. Ich lese meine Programme "wie ein Buch".
@Unit605
so unterschiedlich kann die Wahrnehmung sein. Ich finde Franks Postings häufiger schon mal provokativ, aber eigentlich nie wirklich dogmatisch. Ich denke, es gibt sicherlich etliche Beiträge, wo er sich auch mal eines besseren/anderen belehren ließ.
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
bitte sehr! Es widerspricht sich nicht unbedingt, denn soweit ich das verstanden habe ist DSAG <> SAP.Unit605 hat geschrieben: Dickes Danke fuer den Link.
...
Widerspricht sich zwar mit:
Ein Bekannter von mir, der u. a. bei der SAP in der Entwicklungsabteilung gearbeitet hat, meinte dazu, dass sowas nur Leute machen, die nicht programmieren können.
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
Ich habe Programme gesehen, da haettest Du Dir so eine Vorschrift gewuenscht, nicht in Deutschland, aber in den USA.zzcpak hat geschrieben: Dann benötigt man auch keine Vorschriften im Code Inspector, wieviele Kommtarzeilen anteilig zu vergeben sind
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
DAS ist das Problem, wobei ich die DSAG kaum heranziehen würde, wenn es darum geht..... Wäre es aus der Welt, gäbe es das Thema hier ja nicht.Alexander D. hat geschrieben:So ganz aus der Welt scheint diese Vorgehensweise also nicht zu sein:
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Unit605 hat geschrieben:Dickes Danke fuer den Link.
Widerspricht sich zwar mit:
... finde es trotzdem sehr gut.Ein Bekannter von mir, der u. a. bei der SAP in der Entwicklungsabteilung gearbeitet hat, meinte dazu, dass sowas nur Leute machen, die nicht programmieren können.
Du hast offensichtlich entweder nicht verstanden, wer oder was die DSAG ist oder was die mit der SAP zu tun hat.
Nein, durchaus nicht - ich setze mich damit auseinander. Und antworte: Ich diskutiere ergebnisorientiert. Wenn ich anfange, NETT zu werden, gibt es dafür Gründe. Sowas wie "Ralf ist zu schnell gefahren und ist erwischt worden". Oder "Ralf hat eine Projektverzögerung zu verantworten".Unit605 hat geschrieben:Der Ton macht die Musik. Ich weiss, das trifft bei Dir auf taube Ohren.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wie kommst Du jetzt darauf?ralf.wenzel hat geschrieben:Unit605 hat geschrieben:Dickes Danke fuer den Link.
Widerspricht sich zwar mit:
... finde es trotzdem sehr gut.Ein Bekannter von mir, der u. a. bei der SAP in der Entwicklungsabteilung gearbeitet hat, meinte dazu, dass sowas nur Leute machen, die nicht programmieren können.
Du hast offensichtlich entweder nicht verstanden, wer oder was die DSAG ist oder was die mit der SAP zu tun hat.
Die Aussage Deines Bekannten sagt aus, dass die Leute bei der DSAG nicht programmieren koennen.
Ungeachtet dabei, was die mit der SAP zu tun haben oder nicht.
Wenn ich mir hier im Forum Threads ansehen, wo Fragen gestellt werden und geantwortet wird, komme ich auch hier zu dem Ergebnis (lt. Deinem Bekannten), dass die meisten hier im Forum gar nicht programmieren koennen.
Ich glaube ihr nehmt das Thema viel zu ernst, "Nicht der Weg ist das Ziel" .
Das werden einige vehemend anders sehen, aber im Endeffekt muss das Ergebniss professionell in adäquater Zeit erreicht werden.
Wenn man sich dabei an gewissen Regeln hält gut, wenn nicht dann halt nicht.
Entscheiden wird letztendlich immer der syntaxchecker.
Das werden einige vehemend anders sehen, aber im Endeffekt muss das Ergebniss professionell in adäquater Zeit erreicht werden.
Wenn man sich dabei an gewissen Regeln hält gut, wenn nicht dann halt nicht.
Entscheiden wird letztendlich immer der syntaxchecker.
<:: XING-Gruppe Tricktresor::>
Es gibt Programmierer, die schreiben einen les- und wartbaren Code von alleine, anderen muss mittels StylGuide ein strenges Korset angelegt werden. Ob das Korset jetzt aber die les- und wartbarkeit eines Codes wirklich verbessert hängt vom StylGuide ab.ratsnus hat geschrieben:Wenn man sich dabei an gewissen Regeln hält gut, wenn nicht dann halt nicht.
Bei den "modernen Entwicklungsprozessen" kann ich ganz klar passen. ABAP-OO, ADT, UML, etc. haben ganz klar ihre Daseinsberechtigung, sind hier aber aktuell Kanonen, die man für Spatzen nun wirklich nicht braucht. Wenn die Anforderungen nicht über Reports und einen einfachen Modulpool für die Datenschnellerfassung hinaus gehen, komme ich mit dem klassischen ABAP sehr gut klar.
In Ralfs "Projekt" werden aber anscheinend ganz andere Anforderungen gestellt (Java interagiert mit ABAP über XML und das evtl. noch mit Zertifizierung), dann mögen all die neuen Tools Sinn machen. Es wird aber nicht einfach sein diese Tools "alten" ABAPler schmackhaft zu machen.
Gruß Hendrik
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Das ist völlig egal, wie schmackhaft das ist. Wenn die Anforderungen das hergeben und der Chef will, dass mit Eclipse gearbeitet wird (weil das hier alle machen, SAP-Entwickler sind hier nicht die einzigen Entwickler und wahrscheinlich nichtmal die wichtigsten), dann hat man das zu tun.JHM hat geschrieben:In Ralfs "Projekt" werden aber anscheinend ganz andere Anforderungen gestellt (Java interagiert mit ABAP über XML und das evtl. noch mit Zertifizierung), dann mögen all die neuen Tools Sinn machen. Es wird aber nicht einfach sein diese Tools "alten" ABAPler schmackhaft zu machen.
Ich sitze hier bei einem Kunden, wo Webanwendungen Trumpf sind, wir schicken eine Menge Zeugs ins Portal, wo die Daten dann abgerufen werden. Ich bin sicher, dass die meisten Anwender nichtmal wissen, dass die Daten aus dem SAP kommen (und das ist eine optimistische Schätzung, wahrscheinlich weiß das gar keiner).
So einfach ist die Welt manchmal
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Weil du mit der DSAG kommst und damit belegen willst, dass die Aussage des Ex-SAPlers dem widerspricht. Fakt ist, dass die DSAG nicht die SAP ist und nicht für sie spricht.Unit605 hat geschrieben: Wie kommst Du jetzt darauf?
Und zu der anderen Sache: Ich spreche NIEMANDEM ab, programmieren zu können und die Aussage des Bekannten ist sicher auch polarisierend. Ich denke nur, dass viele (die dennoch programmieren können) ziemlich unkritisch Dinge übernehmen, die man eigentlich nicht übernehmen sollte. Gründe dafür habe ich genug genannt und bisher sind sie auch nicht widerlegt worden (zum Beispiel die Aussage, dass die Deklaration eh nur einen Doppelklick weg ist und die Frage, was IN der Tabelle/Feld/Struktur ist, erheblich schwieriger zu beantworten ist - weshalb es Sinn macht, eben DAS in den Namen reinzuschreiben. Das kann man auch nicht widerlegen, weil die Aussage objektiv wahr ist).
Zu dem Vorschlag (war nicht von dir) LT_EKKO_BESTELLUNGEN - dann will ich aber einen Aufschlag für die Tipperei auf meinen Stundensatz
Ein anderes Beispiel: Ich kenne etliche Codings, wo steht:
Code: Alles auswählen.
constants:
gc_x type c value 'X',
gc_1 type c value '1',
gc_a type c value 'A'.....Das stand bei denen in den Programmierrichtlinien. Alles Entwickler mit mehr als 10 Jahren Erfahrung. Die KÖNNEN programmieren, aber diesen Mist haben sie trotzdem immer weiter gemacht, weil das so in den Regeln steht und weil man das immer schon so gemacht hat.
Übrigens: Jetzt steht es da nicht mehr drin *fg
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Da ich das Buch gerade vor mir liegen habe:ewx hat geschrieben:Tut sie das?ralf.wenzel hat geschrieben:Die SAP lässt "uns" mit dem Thema ja allein.
Buch: ABAP Programmierrichtlinien
(Quelle: Seite 92, Absatz 1 des o. g. Buches)Die technischen Informationen zu einem Repository-Objekt oder einer programminternen Entität sind in der ABAP Workbench oft direkt zu sehen, werden über eine Quickinfo angezeigt oder ins lediglich einen Doppelklick weit entfernt. Die Semantik einer Variablen lässt sich dagegen ohne entsprechende Informationen im Bezeichnet für den Leser oft ungleich schwerer herausfinden als rein technische Typinformationen.
Das ist so ziemlich genau das, was ich hier die ganze Zeit schrieb: Die Deklaration ist nur einen Doppelklick weit weg, aber ob eine LT_EKKO nun Anfragen, Angebote oder Bestellungen oder gar Umlagerungs-, Retouren-, oder CC-Bestellungen enthält, ist eben nicht so einfach zu ermitteln. Daher macht es eher Sinn, eine Solche Tabelle UMBEST, CCBEST, ANGEB oder ähnlich zu benennen.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4159 / 136 /
960
)
»
Warum eigentlich immer dieses Entweder/Oder? Nenne deine Tabellen LT_UMBEST oder von mir aus sogar LT_EKKO_UMBEST und du machst beide Lager glücklich.ralf.wenzel hat geschrieben:Das ist so ziemlich genau das, was ich hier die ganze Zeit schrieb: Die Deklaration ist nur einen Doppelklick weit weg, aber ob eine LT_EKKO nun Anfragen, Angebote oder Bestellungen oder gar Umlagerungs-, Retouren-, oder CC-Bestellungen enthält, ist eben nicht so einfach zu ermitteln. Daher macht es eher Sinn, eine Solche Tabelle UMBEST, CCBEST, ANGEB oder ähnlich zu benennen.
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Unbeantwortete Forenbeiträge
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor 3 Wochen von JanR 1 / 94832
vor 3 Wochen von JanR 1 / 94832
F6862 - Stücklistenpositionen Massenhinzufügen ohne Änderungsnummer
April 2026 von Radinator 1 / 157388
April 2026 von Radinator 1 / 157388