Moderne Entwicklungsprozesse bei SAPlern
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
ich frage mich jedes mal warum diese Diskussion so erbittert geführt werden soll. Ob bei mir im SE80 die Tabelle nun LT_EKKO oder BESTELLUNGEN heisst, in beiden Fällen habe ich keine Gewissheit wie die Tabelle aufgebaut ist. Ich werde in beiden Fällen einen Dopelklick auf den Tabellennamen machen, in die Deklaration springen und mir dort die Tabellenstruktur sowie ggf. die Kommentare zu der Tabelle anschauen. In diesem Fall gibt es in meinen Augen kein fichtig oder falsch.
@zzcpak: die Vorgabe mit einem Kommentar alle 12 Zeilen ist ja stark. Hätte nie geglaubt dass sowas irgendwo tatsächlich als Richtlinie existiert
@zzcpak: die Vorgabe mit einem Kommentar alle 12 Zeilen ist ja stark. Hätte nie geglaubt dass sowas irgendwo tatsächlich als Richtlinie existiert
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
In 'fremden' Programmen gebe ich Dir recht.Alexander D. hat geschrieben: Ob bei mir im SE80 die Tabelle nun LT_EKKO oder BESTELLUNGEN heisst, in beiden Fällen habe ich keine Gewissheit wie die Tabelle aufgebaut ist. Ich werde in beiden Fällen einen Dopelklick auf den Tabellennamen machen, in die Deklaration springen und mir dort die Tabellenstruktur sowie ggf. die Kommentare zu der Tabelle anschauen. In diesem Fall gibt es in meinen Augen kein fichtig oder falsch.
In meinen eigenen Programmen kann ich Dir, ohne nachzusehen, sagen, wie die internen Tabellen aufgebaut sind oder ob man mit Doppelklick nachsehen muss.
D.h. ich kann meine Programme wesentlich schneller und leichter lesen und auch wesentlich schneller und einfacher pflegen.
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
das ist sicherlich bei jedem Entwickler soUnit605 hat geschrieben: D.h. ich kann meine Programme wesentlich schneller und leichter lesen und auch wesentlich schneller und einfacher pflegen.
gilt das auch für das Programm XY05 das du mal vor 5 Jahren auf die Schnelle erstellt hast? Also ich habe damit so meine Probleme, so ein Doppelklick ist aber schnell gemachtUnit605 hat geschrieben: In meinen eigenen Programmen kann ich Dir, ohne nachzusehen, sagen, wie die internen Tabellen aufgebaut sind oder ob man mit Doppelklick nachsehen muss.
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
ralf.wenzel hat geschrieben:Meine persönliche Meinung dazu ist: Bei IMPORTING/USING-Parametern ist es vielleicht sinnvoll, sie zu kennzeichnen, weil man sie nicht ändern kann, bei EXPORTING im Zweifel auch, weil man sie initialisieren muss, [...]
Passt das zusammen?ralf.wenzel hat geschrieben:Ich verwende gern die Option Aktualparameter = Formalparameter. Das kann man total vergessen, wenn man irgendwelche Präfixe setzen muss.
~~~~~~~~~~~~~~~~~~~~
Die Funktionen, die ADT bietet, sind IMHO anders zu bewerten, als ein Muster einzufügen. Bei globaler Ersetzung eines Variablennamens muss ich mich darauf verlassen können, dass es funktioniert. In der Regel tut es das und ich kann es dann auch verwenden. Beim Einfügen eines Musters zum Aufruf eines Funktionsbausteins oder einer Methode muss ich doch die Parameter überprüfen. Wenn ich das tue, kann ich auch die Anpassungen vornehmen. In der Regel passen die eh nicht. gerade dann, wenn man im BAPI-Umfeld arbeitet oder seine Variablennamen nicht MATNR oder VBELN nennt.
Ich sehe nichts Schlimmes daran, ein Präfix zu verwenden, dass den Typ der Variablen anzeigt. Eine Definition dafür, ob es sich um einen Zähler oder einen Betrag oder ein Flag handelt, kann man ja trotzdem verwenden. Ich halte es jedenfalls für sinnvoll, dass man auf den ersten Blick erkennen kann, ob mit dem Clear eine Tabelle, ein Feld oder eine Objektreferenz löscht.
Zu Variablennamen allgemein:
1. den technischen Typ zu verwenden, hat häufig den Vorteil, dass man ihn kennt. Man weiß als SAP-Programmierer MATNR ist eine Materialnummer. Basta. Kein Flag, keine Tabelle, kein Equipment, kein Zähler. Wenn ich die Variablennamen beschreibend vergebe, gibt es bei 5 Programmierern 8 verschiedene Namen (service_material_number, mat_for_service, srv_mat,...) Gerade wenn dann noch englische Begriffe verwendet werden, weiß man nicht mehr, ob man den Spediteur nun "carrier" oder "forwarder" oder "forwarding agent" oder was auch immer nennen soll.
2. man kann sich auch durchaus streiten, ob man für lokale Variablen einen präfix LT_ LS_ etc. benötigt bzw. ob man bei Methoden mit wenig Parametern diese mit IV_ oder ET_ deklarieren muss.
Wenn man es allerdings macht, dann ist es deutlich, dass der Programmierer ein System hat. Wenn ich in einem Programm auf "ungepräfixte" Variablen treffe, muss ich mich immer fragen: "hat der das nun nur in der lokalen methode gemacht, oder macht der das auch bei globalen Variablen?". Und schon kann ich mir nicht sicher sein, ob die verwendeten Variablen lokal oder global definiert sind.
3. Für Feldsymbole verwende ich fast nie einen Präfix, da diese (fast) immer lokal definiert sind. Bei Methoden immer. Da geht's gar nicht anders.
Das ist genau das Problem an der Diskussion: Jeder ist sich und seinen Gewohnheiten am nächsten. Der nächste, der an das Programm ran muss, kann dann sehen, wo er bleibt. Auf bestimmte Eigenarten kann man sich (muss man sich) einstellen. Schneller geht's, wenn man sich an gewisse "Standards" hält. Das die sich mit der Zeit ändern, ist klar.Unit605 hat geschrieben: In 'fremden' Programmen gebe ich Dir recht.
In meinen eigenen Programmen kann ich Dir, ohne nachzusehen, sagen, wie die internen Tabellen aufgebaut sind oder ob man mit Doppelklick nachsehen muss.
D.h. ich kann meine Programme wesentlich schneller und leichter lesen und auch wesentlich schneller und einfacher pflegen.
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Oha, ich bin davon sogar SEHR überzeugt. Bei meinem aktuellen Kunden dreht man gerade gepflegt frei, weil hier ALLE in Eclipse arbeiten, nur die SAPler nicht (SE80 hat für die was von "Mit Nagelscheren Löcher in Lochkarten schneiden"). Gerade bei den Mixed-Projekten, die hier die Mehrzahl sind (hier ein bisschen Java, da ein bisschen ABAP, schön garniert mit XML-Krams) wird sich das auszahlen, so hofft man hier.zzcpak hat geschrieben:Von ADT bin ich noch nicht wirklich überzeugt, auch wenn es einige chice Gimmicks bietet. Bin aber mal gespannt, wohin der Weg da noch führt.
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
)
»
Hallo Ralf,
In (großen) Teilen beschreibst du tatsächlich den Zustand, den auch ich vorfinde - aber du bewertest das völlig anders als ich.
1.) (ungarische) Notationen / Programierrichtlinien:
Warum wendet man so etwas an? Damit man beim kurzen Drüberschauen schneller weiß womit man es (wahrscheinlich) zu tun hat. Welche Art von Regelwerk hier letztlich angewendet wird ist egal solange es nur konsequent durchgeführt wird. Wenn mein Kunde also meint dass seine Programme von den eigenen Leuten leichter gewartet werden können, wenn alle Variablen mit 5stelligen Präfixen beginnen und über das gesamte Programm betrachtet einen 6-hebigen Jambus bilden müssen werde ich mir meinen Teil dazu denken. Wenn ich gute Laune habe verrate ich dem Kunden auch meine Gedanken - aber er zahlt letztlich und ist damit König.
Wenn keine Richtlinien vorhanden sind ( tjaja - soll es geben ) verwende ich tatsächlich so was wie die LT_,.... Präfixe weil ich damit recht gut zurecht komme. Ich schäme mich auch nicht dafür. Und es bereitet mir auch keine schlaflosen Nächte wenn ein Feldsymbol mal nicht 100%ig sauber benamt wurde.
2.) Da kommt nun Eclipse daher und alles wird anders:
Find ich ja alles ganz toll - aber die meisten meiner Kunden (und ich damit auch) werden auf die neuen Kernels ( 7.4 aufwärts ) wohl noch ein paar Jährchen verzichten so sie denn mit dem alten gut über die Runden kommen. Und was ich bisher in Eclipse gesehen habe ist ja ganz nett für den Anfang - aber wir sind bei weitem noch nicht da wo wir sein sollten. ( kannst mich ja mal anpingen - habe da ein paar Informationsbröckchen, die sonst wohl nicht in der Form im Netz rumgeistern )
3.) Erziehungsauftrag:
Ich habe Mathematik studiert und nicht Pädagogik. Hat auch seinen Grund gehabt. Wenn mich jemand fragt bin ich gerne bereit meine Erfahrungen weiterzugeben oder Hinweise zur besseren/anderen Programmierung. Aber für viele Firmen reichen die Durchschnittsprogrammierer doch für das Gros der Arbeiten aus ohne auf die neuesten Methoden aufspringen zu müssen. Und "Durchschnitt" heißt nicht schlecht, so lange die Arbeit sauber gemacht wird! Schlussendlich lebst du doch sogar von dieser Situation, dass dein Wissen gebraucht wird wo das inhäusige nicht mehr ausreicht.
Sieh dein Wissen an wie Religion. Missionare werden nicht gern gesehen - aber wenn du auf fruchtbaren Boden triffst dann ertränke alle mit deinem Wissen.
4.) ganz speziell Unit-Tests
Das ist so eins meiner Lieblingsthemen. Ich habe bisher noch keinen Kunden gehabt, wo ich das hätte einbauen müssen. In der Theorie ist das was ganz Schickes - aber wenn das Geld/Zeit knapp werden ist das die erste Stelle an der gespart wird. Ich denke schon länger darüber nach, wenn ich eine neue Methode schreibe, ob ich da nicht einen Unit-test hinterklemmen könnte. Aber fast immer stellt sich raus, dass das Ergebnis der Methode von zu vielen Parametetern ( Customizing, Belege ) abhängt oder einfach trivial ist. Und da nach meiner Erfahrung die Anforderungen an ein Programm sich im Laufe der Programmierung stark ändern, sobald der Kunde zum 1. Mal sieht was er eigentlich gefordert hatte lohnt sich der Aufwand am Anfang selten.
Das Einzige mal wo ich das bisher sinnvoll eingesetzt habe war eine Zusammenarbeit bei einem OpenSource Projekt ( ABAP2XLSX ) wo wir tatsächlich eine Reihe von Testfällen vorgeben konnten deren Ergebnis nachher abgeprüft wurde. Aber in der Praxis sieht das etwa so aus. " Wenn folgende Bedingungen gelten muss das hier rauskommen. Ich habe dir 3 Testbeispiele auf dem Entwicklungssystem hingestellt". Dumm nur, wenn das Durchlaufen der Methode das Testbeispiel verbraucht.
Ich glaube dass du einfach eine zu dünne Haut hast.ralf.wenzel hat geschrieben:Wie sind eure Beobachtungen? Ist UML bei euren Kunden ein Begriff? Gibt es dort definierte Entwicklungs-, Test- und Abnahmeszenarien? Ist meine Beobachtung repräsentativ oder gerate ich einfach immer nur an die falschen Kunden?
In (großen) Teilen beschreibst du tatsächlich den Zustand, den auch ich vorfinde - aber du bewertest das völlig anders als ich.
1.) (ungarische) Notationen / Programierrichtlinien:
Warum wendet man so etwas an? Damit man beim kurzen Drüberschauen schneller weiß womit man es (wahrscheinlich) zu tun hat. Welche Art von Regelwerk hier letztlich angewendet wird ist egal solange es nur konsequent durchgeführt wird. Wenn mein Kunde also meint dass seine Programme von den eigenen Leuten leichter gewartet werden können, wenn alle Variablen mit 5stelligen Präfixen beginnen und über das gesamte Programm betrachtet einen 6-hebigen Jambus bilden müssen werde ich mir meinen Teil dazu denken. Wenn ich gute Laune habe verrate ich dem Kunden auch meine Gedanken - aber er zahlt letztlich und ist damit König.
Wenn keine Richtlinien vorhanden sind ( tjaja - soll es geben ) verwende ich tatsächlich so was wie die LT_,.... Präfixe weil ich damit recht gut zurecht komme. Ich schäme mich auch nicht dafür. Und es bereitet mir auch keine schlaflosen Nächte wenn ein Feldsymbol mal nicht 100%ig sauber benamt wurde.
2.) Da kommt nun Eclipse daher und alles wird anders:
Find ich ja alles ganz toll - aber die meisten meiner Kunden (und ich damit auch) werden auf die neuen Kernels ( 7.4 aufwärts ) wohl noch ein paar Jährchen verzichten so sie denn mit dem alten gut über die Runden kommen. Und was ich bisher in Eclipse gesehen habe ist ja ganz nett für den Anfang - aber wir sind bei weitem noch nicht da wo wir sein sollten. ( kannst mich ja mal anpingen - habe da ein paar Informationsbröckchen, die sonst wohl nicht in der Form im Netz rumgeistern )
3.) Erziehungsauftrag:
Ich habe Mathematik studiert und nicht Pädagogik. Hat auch seinen Grund gehabt. Wenn mich jemand fragt bin ich gerne bereit meine Erfahrungen weiterzugeben oder Hinweise zur besseren/anderen Programmierung. Aber für viele Firmen reichen die Durchschnittsprogrammierer doch für das Gros der Arbeiten aus ohne auf die neuesten Methoden aufspringen zu müssen. Und "Durchschnitt" heißt nicht schlecht, so lange die Arbeit sauber gemacht wird! Schlussendlich lebst du doch sogar von dieser Situation, dass dein Wissen gebraucht wird wo das inhäusige nicht mehr ausreicht.
Sieh dein Wissen an wie Religion. Missionare werden nicht gern gesehen - aber wenn du auf fruchtbaren Boden triffst dann ertränke alle mit deinem Wissen.
4.) ganz speziell Unit-Tests
Das ist so eins meiner Lieblingsthemen. Ich habe bisher noch keinen Kunden gehabt, wo ich das hätte einbauen müssen. In der Theorie ist das was ganz Schickes - aber wenn das Geld/Zeit knapp werden ist das die erste Stelle an der gespart wird. Ich denke schon länger darüber nach, wenn ich eine neue Methode schreibe, ob ich da nicht einen Unit-test hinterklemmen könnte. Aber fast immer stellt sich raus, dass das Ergebnis der Methode von zu vielen Parametetern ( Customizing, Belege ) abhängt oder einfach trivial ist. Und da nach meiner Erfahrung die Anforderungen an ein Programm sich im Laufe der Programmierung stark ändern, sobald der Kunde zum 1. Mal sieht was er eigentlich gefordert hatte lohnt sich der Aufwand am Anfang selten.
Das Einzige mal wo ich das bisher sinnvoll eingesetzt habe war eine Zusammenarbeit bei einem OpenSource Projekt ( ABAP2XLSX ) wo wir tatsächlich eine Reihe von Testfällen vorgeben konnten deren Ergebnis nachher abgeprüft wurde. Aber in der Praxis sieht das etwa so aus. " Wenn folgende Bedingungen gelten muss das hier rauskommen. Ich habe dir 3 Testbeispiele auf dem Entwicklungssystem hingestellt". Dumm nur, wenn das Durchlaufen der Methode das Testbeispiel verbraucht.
sogar dabei ist in unseren Programmierrichtlinien ein Präfix vorgeschrieben. Auch das finde ich ggfs. sinnvoll. Damit weiss man gleich, ob das gute Stück auf eine einfache Variable oder einen Arbeitsbereich zeigt.ewx hat geschrieben:3. Für Feldsymbole verwende ich fast nie einen Präfix, da diese (fast) immer lokal definiert sind. Bei Methoden immer. Da geht's gar nicht anders.
Aber halten wir uns nicht zu sehr an diesem Punkt auf? Präfixe sehe ich eher als kosmetisches Problem.
Ich denke, wir sind uns einig, dass Pauschalisierungen à la "ABAP OO ist kagge" oder "nur ABAP OO" oder "niemals SELECT *" wenig zielführend sind.
Dem stimme ich zu. Die Frage wäre doch dann, was kann man als "verantwortungsvoller" Entwickler tun, damit ggfs. der Nachfolgeentwickler nicht wie ein Ochs vorm Berg vor dem vererbten Coding steht und es lieber neuschreiben als ändern wollteewx hat geschrieben: Das ist genau das Problem an der Diskussion: Jeder ist sich und seinen Gewohnheiten am nächsten. Der nächste, der an das Programm ran muss, kann dann sehen, wo er bleibt. Auf bestimmte Eigenarten kann man sich (muss man sich) einstellen. Schneller geht's, wenn man sich an gewisse "Standards" hält. Das die sich mit der Zeit ändern, ist klar.
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Nein, das passt in der Tat derzeit nicht zusammen und ich ringe mit mir, welchen Weg ich gehen sollte. Auf der einen Seite ist der Hinweis "das kannst du nicht ändern" ganz praktisch, auf der anderen Seite: Was auf der einen Seite ein Exporting-Parameter ist, kann auf der anderen Seite ein Importing-Parameter sein. Und dann wechselt das Präfix hin und her und verwirrt eher als dass es aufklärt.ewx hat geschrieben:ralf.wenzel hat geschrieben:Meine persönliche Meinung dazu ist: Bei IMPORTING/USING-Parametern ist es vielleicht sinnvoll, sie zu kennzeichnen, weil man sie nicht ändern kann, bei EXPORTING im Zweifel auch, weil man sie initialisieren muss, [...]Passt das zusammen?ralf.wenzel hat geschrieben:Ich verwende gern die Option Aktualparameter = Formalparameter. Das kann man total vergessen, wenn man irgendwelche Präfixe setzen muss.
Und dann ist da noch die SAP, die in Schnittstellen ständig Präfixe setzt, die man dann selbst wieder rauswerfen muss, wenn man es so haben will wie ich.
Richtig.ewx hat geschrieben:Die Funktionen, die ADT bietet, sind IMHO anders zu bewerten, als ein Muster einzufügen.
Aber es ist auf jeden Fall ein Hinweis. Ich schreibe gerade an einem Programm, dass mit Normalbestellungen und Retourenbestellungen arbeitet. Ich selektiere aus den EK*-Tabellen einige Daten davon und nenne die resultierenden Tabellen retbest und normbest (oder von mir aus lt_retbest und lt_normbest). Dann ist sofort klar, was drin ist. Dass letztlich EK*-Felder (nicht zwingend EKKO, was soll ich mit der Kopie der gesamten Tabellenbreite?) drin sind, ergibt sich aus Kontext oder Doppelklick. Ich bin übrigens ein Freund davon, solche Beschreibungen in deutscher Sprache zu halten, es sei denn, man hat es wirklich mit internationalen Teams zu tun, was selten der Fall ist.ewx hat geschrieben:1. den technischen Typ zu verwenden, hat häufig den Vorteil, dass man ihn kennt. Man weiß als SAP-Programmierer MATNR ist eine Materialnummer. Basta. Kein Flag, keine Tabelle, kein Equipment, kein Zähler. Wenn ich die Variablennamen beschreibend vergebe, gibt es bei 5 Programmierern 8 verschiedene Namen (service_material_number, mat_for_service, srv_mat,...) Gerade wenn dann noch englische Begriffe verwendet werden, weiß man nicht mehr, ob man den Spediteur nun "carrier" oder "forwarder" oder "forwarding agent" oder was auch immer nennen soll.
Doppelklick drauf und du weißt esewx hat geschrieben:Wenn man es allerdings macht, dann ist es deutlich, dass der Programmierer ein System hat. Wenn ich in einem Programm auf "ungepräfixte" Variablen treffe, muss ich mich immer fragen: "hat der das nun nur in der lokalen methode gemacht, oder macht der das auch bei globalen Variablen?". Und schon kann ich mir nicht sicher sein, ob die verwendeten Variablen lokal oder global definiert sind.
Was ich aber NICHT mit einem Doppelklick ermitteln kann, ist: Was ist in der Tabelle drin? Ist LT_EKKO1 nun die mit den Normalbestellungen oder die mit den Umlagerungsbestellungen?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. Ganz ehrlich: Da hab ich lieber die weniger wenig naheliegenden Dinge erklärt als die, die nur einen Doppelklick entfernt sind. Und in Eclipse muss ich nichtmal mein Coding verlassen (um per Doppelklick ins TOP-Include zu springen), sondern kriege das schön im Fenster eingeblendet.Unit605 hat geschrieben: In 'fremden' Programmen gebe ich Dir recht.
In meinen eigenen Programmen kann ich Dir, ohne nachzusehen, sagen, wie die internen Tabellen aufgebaut sind oder ob man mit Doppelklick nachsehen muss.
Richtig. Leider hat die nie jemand erarbeitet und bei der SAP selbst machts jeder wie er will. Da hab ich schon alles gesehen von L_T_TABLE über LT_TABLE und L_TABLE hin zu TABLE. Wie gesagt: Ungarische Notation ist das alles nicht. Nur Abguckerei a la "das ist von der SAP, dann ist das sicher gut".ewx hat geschrieben:Schneller geht's, wenn man sich an gewisse "Standards" hält. Das die sich mit der Zeit ändern, ist klar.
Und dass die sich ändern, bestreite ich, weil man das aus den Leuten nicht rauskriegt, so falsch und wenig sinnvoll es auch immer aussehen mag. Inzwischen sieht man diese Präfixe LT und LS und ähnliche kaum noch bei der SAP.
ABAP hat sich gewandelt. Von einer ziemlich schlechten Programmiersprache (ich sag nur: if ( a + b ) > c oder "with header line", was zu zwei Variablen gleichen Namens führt) hin zu einer ziemlich guten. Dem sollte man Rechnung tragen.
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
)
»
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.
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
)
»
Komisch. Ich weiß das ziemlich oft gar nicht, wenn ich das Programm schreibe. Gerade bei Feldsymbolen nicht.zzcpak hat geschrieben:sogar dabei ist in unseren Programmierrichtlinien ein Präfix vorgeschrieben. Auch das finde ich ggfs. sinnvoll. Damit weiss man gleich, ob das gute Stück auf eine einfache Variable oder einen Arbeitsbereich zeigt.
Man sollte sich mal zusammensetzen und sowas wie ein "Handbuch für gutes Coding" schreiben - aber dazu müssten sich genug Leute erstmal einig werdenzzcpak hat geschrieben:Dem stimme ich zu. Die Frage wäre doch dann, was kann man als "verantwortungsvoller" Entwickler tun, damit ggfs. der Nachfolgeentwickler nicht wie ein Ochs vorm Berg vor dem vererbten Coding steht und es lieber neuschreiben als ändern wollte
Die SAP lässt "uns" mit dem Thema ja allein.Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich finde <LS_..> sieht einfach unschön aus...zzcpak hat geschrieben:sogar dabei ist in unseren Programmierrichtlinien ein Präfix vorgeschrieben. Auch das finde ich ggfs. sinnvoll. Damit weiss man gleich, ob das gute Stück auf eine einfache Variable oder einen Arbeitsbereich zeigt.ewx hat geschrieben:3. Für Feldsymbole verwende ich fast nie einen Präfix, da diese (fast) immer lokal definiert sind. Bei Methoden immer. Da geht's gar nicht anders.
Ja, das ist Kleinkram. Trotzdem kann man sich herrlich lange darüber streiten. Wirklich erstaunlich...zzcpak hat geschrieben:Aber halten wir uns nicht zu sehr an diesem Punkt auf? Präfixe sehe ich eher als kosmetisches Problem.
Ich denke, wir sind uns einig, dass Pauschalisierungen à la "ABAP OO ist kagge" oder "nur ABAP OO" oder "niemals SELECT *" wenig zielführend sind.
Das ist ein schwieriges Thema und hängt davon ab, was für einen Anspruch der Kunde hat.zzcpak hat geschrieben:Dem stimme ich zu. Die Frage wäre doch dann, was kann man als "verantwortungsvoller" Entwickler tun, damit ggfs. der Nachfolgeentwickler nicht wie ein Ochs vorm Berg vor dem vererbten Coding steht und es lieber neuschreiben als ändern wollteewx hat geschrieben: Das ist genau das Problem an der Diskussion: Jeder ist sich und seinen Gewohnheiten am nächsten. Der nächste, der an das Programm ran muss, kann dann sehen, wo er bleibt. Auf bestimmte Eigenarten kann man sich (muss man sich) einstellen. Schneller geht's, wenn man sich an gewisse "Standards" hält. Das die sich mit der Zeit ändern, ist klar.
Wenn ich mein Auto zum Tunen in die Werkstatt bringe, dann erwarte ich, dass es professionell gemacht wird. Dann ist mein Anspruch nicht, dass ich mit meinem Kreuzschlitzschraubendreher den Spoiler selbst abschrauben kann. Allerdings erwarte ich, dass es keine Klebereste gibt und dass der Spoiler nicht bei 220 km/h abfällt. (Huch, war das grade eine Analogie, die nichts mit "Kochen" zu tun hatte...?)
Dem SAP-Kunden wird es in der Regel auch so gehen: Das Programm soll professionell programmiert sein. Der Kunde muss und will gar nicht verstehen, wie es funktioniert. Aber es muss auch von einem anderen professionellen Entwickler gewartet werden können.
Wenn der Kunde erwartet, dass die eigenen Entwickler das Programm selbst warten können, dann kann man darauf Rücksicht nehmen, oder man sagt: Tut mir leid, so arbeite ich nicht.
Und auch bei professionell gibt es ja eine gewisse Bandbreite... Wie viele erfahrene Entwickler können z.B. ein in SAP verwendetes Entwurfsmuster erkennen (Singleton und Factory mal aussen vor gelassen).
Tut sie das?ralf.wenzel hat geschrieben:Die SAP lässt "uns" mit dem Thema ja allein.
Buch: ABAP Programmierrichtlinien
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Weil ich frage, wie es bei anderen Kunden läuft?black_adept hat geschrieben:Hallo Ralf,Ich glaube dass du einfach eine zu dünne Haut hast.ralf.wenzel hat geschrieben:Wie sind eure Beobachtungen? Ist UML bei euren Kunden ein Begriff? Gibt es dort definierte Entwicklungs-, Test- und Abnahmeszenarien? Ist meine Beobachtung repräsentativ oder gerate ich einfach immer nur an die falschen Kunden?
Das frage ich JEDEN Kunden, ehrlich. Und ich bekomme immer zur Antwort: Weil die SAP das auch so macht. Dass sie das schon lange nicht mehr so macht und nie konsequent durchgezogen haben, wissen die nicht. Die wissen auch nicht, dass es Ungarische Notation gibt und wie die *korrekt* aussieht.black_adept hat geschrieben:Warum wendet man so etwas an?
Sprich: Du betrachtest dich als ausführendes Organ (ich hätte fast "Tippkraft" geschrieben, aber damit würde ich dich beleidigen - was ich explizit NICHT tun möchte)? Ich betrachte mich als Berater und wenn ein Kunde in meinen Augen Mist macht, dann sag ich ihm das. In vielen Dingen wird das durchaus positiv aufgenommen.ralf.wenzel hat geschrieben:Wenn ich gute Laune habe verrate ich dem Kunden auch meine Gedanken - aber er zahlt letztlich und ist damit König.
Bei einem Kunden hab ich ne Weile rumgemeckert, dass keiner weiß, was der andere tut. "Ach, Sie haben Kritik an unserem Entwicklungsprozess zu äußern?" - "Nein, ich übe Kritik daran, dass Sie gar keinen definierten Entwicklungsprozess haben". Daraufhin habe ich zwei Vorträge gehalten und die Einführung des Solution Managers wurde beschlossen
Hm, mein derzeitiger Kunde überlegt, u. a. WEGEN ADT schneller hochzuwechseln.ralf.wenzel hat geschrieben:Find ich ja alles ganz toll - aber die meisten meiner Kunden (und ich damit auch) werden auf die neuen Kernels ( 7.4 aufwärts ) wohl noch ein paar Jährchen verzichten so sie denn mit dem alten gut über die Runden kommen.
Und ja, ich sehe durchaus, dass eine Menge NICHT geht, von dem was man mal haben will. Softwareerstellung ist ein Prozess, eine Software, die fertig ist, wird nicht mehr weiterentwickelt. Software, die nicht mehr weiterentwickelt wird, ist tot.
Aber du musst doch irgendwie Testszenarien aufbauen und sie sowie deren Ergebnisse dokumentieren. Und da man die Änderung ohnehin (hoffentlich!) dokumentiert, hat man schnell einen Stapel Papier zusammen, der sich zusammensetzt aus:black_adept hat geschrieben:Das ist so eins meiner Lieblingsthemen. Ich habe bisher noch keinen Kunden gehabt, wo ich das hätte einbauen müssen. In der Theorie ist das was ganz Schickes - aber wenn das Geld/Zeit knapp werden ist das die erste Stelle an der gespart wird. Ich denke schon länger darüber nach, wenn ich eine neue Methode schreibe, ob ich da nicht einen Unit-test hinterklemmen könnte.
* Anforderung des Fachbereichs
* Umsetzungsvorschlag (technisch) der IT
* Kostenschätzung
* Dokumentation der Änderung
* Testprotokoll
* Genehmigung der Produktivsetzung
Oder kriegst du nen Telefonanruf "Mach ma Transaktion" und du setzt dich hin und rufst zurück "Transaktion is feddisch, buch ma'!"? Bei Firmendaten fände ich das reichlich problematisch und - wie ich schon ausführte - gibt es durchaus Branchen, in denen solches Arbeiten schlichtweg verboten ist.
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
)
»
Das Buch steht auf der Liste der Bücher, die ich lesen werde, wenn Galileo im 21. Jahrhundert angekommen ist, was wohl in einigen Wochen passieren wird. Fachbücher brauche ich bei der Arbeit, darum will ich sie auf dem iPad haben und nicht in zwei Koffern mit mir herumschleppenewx hat geschrieben:Tut sie das?ralf.wenzel hat geschrieben:Die SAP lässt "uns" mit dem Thema ja allein.
Buch: ABAP Programmierrichtlinien
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
)
»
Und du erwartest nicht, dass, wenn du mit einer schlechten Idee kommst und der Fachmann hat eine bessere, dass er sie dir zumindest vorschlägt, ohne dass du ihn explizit nach Verbesserungsvorschlägen fragst?ewx hat geschrieben:Das ist ein schwieriges Thema und hängt davon ab, was für einen Anspruch der Kunde hat.
Wenn ich mein Auto zum Tunen in die Werkstatt bringe, dann erwarte ich, dass es professionell gemacht wird.
Auja, solche Diskussionen führe ich gerade mit einem gemeinsamen Bekannten von uns. Ganz - schweres - Brot.ewx hat geschrieben:Und auch bei professionell gibt es ja eine gewisse Bandbreite...
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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 / 98405
vor 3 Wochen von JanR 1 / 98405
F6862 - Stücklistenpositionen Massenhinzufügen ohne Änderungsnummer
April 2026 von Radinator 1 / 161105
April 2026 von Radinator 1 / 161105