Moderne Entwicklungsprozesse bei SAPlern

Moderne Entwicklungsprozesse bei SAPlern

Moin,

ich will mir einfach mal ein Bild machen davon, wie das andere erleben.

Mein Bild vom Kunden ist geprägt von Entwicklern, die aus dem R/2 kommen und genau so auch programmieren. Testklassen und Ausnahmeklassen kennt da kein Mensch, das Denken ist stark prozedural geprägt, es wird unglaublich stark darauf geachtet, dass Variablen die richtigen Präfixe haben (das ist total witzig, wenn man denen erklären muss, dass sich erst zur Laufzeit entscheidet, was für ein Feld ich da habe), was ich bekanntlich für den größten Unsinn überhaupt halte. 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. 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, aber ansonsten ist die Deklaration immer nur einen Doppelklick (bzw. ein "F2" in Eclipse) entfernt. Dieses LT_/LS_-Geraffel kenne ich aus anderen Programmiersprachen so überhaupt nicht....

Da heißt dann eine Tabelle fröhlich "LT_EKKO", ganz ehrlich: Die Bezeichnung BESTELLUNGEN finde ich viel aussagekräftiger, auch ohne Präfix. EKKO kann viel enthalten, weit mehr als Bestellungen.

Bei einem Kunden ist es verboten(!), Coding zu löschen. Man darf nur auskommentieren (mit Ticketnummer als Zeilenkommentar), was in fünf Jahre allem Coding dann so richtig * aussieht. Da wird dann ein Block eingefügt, später ein Teil davon auskommentiert und durch einen anderen ersetzt, etc. Da schaut dann keiner mehr durch. Wie soll man so gescheit arbeiten?

Ein anderer Bekannter von mir, auch aus dem R/2 ins R/3 hineingewachsen, sagt immer wieder, dass die Implementierung der OO-Funktionalitäten im SAP "absoluter Mist" sei (er kategorisiert gern in schwarz oder weiß, dazwischen gibt es nix). Wenn man ihn dann aber fragt, was er denn konkret meine, sagt er: "Alles". Dabei hat OO einige Vorteile, die auch ich nicht abstreiten kann und ich verwende es zunehmend.

Wie kriege ich so jemanden (gemeint sind alle Beispiele) dazu, sich mit modernen Entwicklungsmethoden auseinanderzusetzen? Was mache ich mit 55jährigen "Programmierern", die immer noch select....endselect und interne Tabellen mit "with header line" verwenden und das dann "Programmieren" nennen und die Fehler reparieren, indem sie nicht etwa Unittests machen (was ohne Unit ja gar nicht geht, man rödelt im ganzen Programm inkl Form-Routinen auf globalen Feldern herum), sondern im Debugger einen Wert beobachten, der falsch ist und sich überlegen "wie kriege ich den auf den richtigen Wert umgebogen?"

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?

ralf *hatte neulich deutlich Ärger, weil er beim Kunden einen Tobsuchtsanfall hatte, bei dem er Dinge gesagt hat, die der Kunde nicht hören wollte....

Re: Moderne Entwicklungsprozesse bei SAPlern

Alexander D. hat geschrieben:Ohne jetzt eine Grundsatzdiskussion vom Zaun zu brechen, das "LT_/LS_-Geraffel" kenne ich von anderen Programmiersprachen schon.

Ich will diese Grundsatzdiskussion auch nicht, aber ich gebe mal das eine oder andere Beispiel:

LOOP AT lt_table INTO <ls_table>.

ENDLOOP.

klingt erstmal gut. Aber was ist bei "lt_table TYPE standard table of MATNR"? Loopt man dann in <lv_table>? Was ist, wenn lt_table eine tiefe Tabelle ist und das Feld "ATTRIBUTES" eine Tabelle enthält? Und da sind wir bei dynamischer Deklaration noch gar nicht angelangt..... Man stößt mit einer so "eindimensionalen" Sichtweise sehr schnell an seine Grenzen.

Edit: Das habe ich eben glatt überlesen, gut dass ich darauf aufmerksam gemacht wurde: Mit ungarischer Notation hat LS_-Geraffel nix zu tun. Wer das meint, der möge sich über die ungarische Notation (und nicht das, was frühe SAP-Entwickler oder Microsoft daraus gemacht haben) informieren... /Edit

Außerdem zu UML: Wie macht ihr eine revisionssichere Dokumentation des Codings?

Re: Moderne Entwicklungsprozesse bei SAPlern

Lustigerweise kommen mir in letzter Zeit immer Vergleiche zum Kochen...

Mit Programmierern einer Firma ist es doch ähnlich wie mit den Köchen:

Es gibt kleine Küchen, da ist der Koch auch noch für das Servieren zuständig und für die Abfertigung der Hotelgäste sowie für die Weihnachtsdekoration.
Es gibt große Küchen, da ist ein Hilfskoch nur für das Schnippeln von Gemüse zuständig. Da ist dann auch genau fest gelegt, wie breit die einzelnen Scheiben bei Gemüsezwiebeln, Lauchzwiebeln und Paprika sein dürfen.
Die eine Küche hat einen Croissantbackautomaten, einen Ananasschneider und spezielle Formen für Mousse au Chocolat.
Da gibt es von jedem Gericht ein Produktbild, wie es am Ende auszusehen hat. Es gibt einen Küchenchef, der nur darauf achtet, dass alle Gerichte korrekt angerichtet sind.

Der eine Koch benutzt ausschließlich Santokimesser direkt aus Japan, der andere benutzt für alles eine Küchenmaschine, weil die zur Verfügung gestellten Messer nichts taugen.
Ein Koch hat eine Vorliebe für frische französische Kräuter und packt selbst auf den Apfelkuchen ein Blatt Minze. Ein anderer kocht lieber etwas mehr und hat keinen Sinn für Schnickschnack wie z.B. Kräuter.

Vieles ist einfach Geschmackssache und es kommt A darauf an, dass es dem Kunden schmeckt und B, dass der Chef es ok findet.

Ebenso denke ich, dass es bei Köchen als auch bei Gästen unterschiedliche Wahrnehmungen gibt. Während der eine Gast zufrieden ist, weil er satt wurde, findet der andere, dass eigentlich eine Prise Thymian an die Bratensoße gehört. Der eine Koch verwendet frische Zutaten und kümmert sich selbst darum, dass diese auch vorhanden sind, der nächste Koch nimmt das, was da ist.

So kann man wahrscheinlich noch mehrere Seiten weiter machen.

Fazit (jedenfalls für mich):
Angebrannte Speisen und dreckige Küchen sind absolut inakzeptabel.
Aber solange sich niemand darüber beschwert, macht jeder auf seine Art und Weise weiter.
So, wie er es gewohnt ist, so wie er geführt wird.

so, ich muss jetzt weiter kochen...

Re: Moderne Entwicklungsprozesse bei SAPlern

ewx hat geschrieben:Vieles ist einfach Geschmackssache und es kommt A darauf an, dass es dem Kunden schmeckt und B, dass der Chef es ok findet.

Naja, wenn solche Regeln bei der Arbeit stören... Ich verwende gern die Option Aktualparameter = Formalparameter. Das kann man total vergessen, wenn man irgendwelche Präfixe setzen muss.

Darüber hinaus ist das LS_/LT_-Geraffel schlichtweg fachlich falsch. Eine treffendere Schilderung als diese hier habe ich noch nirgends gefunden.

Aber jetzt bitte wieder zum eigentlichen Thema: Moderne Arbeitstechniken beim Kunden

Re: Moderne Entwicklungsprozesse bei SAPlern

Also, bei mir sieht eine "Diskussion" eigentlich anders aus.

Totschlagargumente wie:

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.

Darüber hinaus ist das LS_/LT_-Geraffel schlichtweg fachlich falsch.

Aber jetzt bitte wieder zum eigentlichen Thema: Moderne Arbeitstechniken beim Kunden

helfen einer Diskussion nicht.

Wenn Dein Bekannter bei der SAP im Entwicklungsbereich arbeitet, wird er, da er ja bei der SAP arbeitet, auch 100% recht haben. OK, damit kann ich nicht programmieren.

Dieses LS_/LT_Geschafel musst Du bei den meisten Firmen sogar anwenden und dafuer unterschreiben. Das sind die sogenannten Programmierrichtlinien.
Uebrigens finde ich, dass es dort wohl sehr hilfreiches Geschwafel gibt.
Und Dein Beispiel LT_EKKO bedeutet in meine Programmen, dass es sich um eine interne Tabelle des Type EKKO handelt und ich brauche gar nicht nachzusehen, wie die Struktur aufgebaut ist, ich weiss es.
Bei LT_Bestellungen weiss ich erst einmal nur, dass es sich um Bestellungen handelt, aber sonst nichts.
LT_Bestellungen wuerde bei mir ein interne Tabelle heissen, die nicht 100% der EKKO entspricht, aber oft aehnlich.

Wenn Du nur zum Thema: " Thema: Moderne Arbeitstechniken beim Kunden" was schreiben und hoeren willst, fange nicht selber damit an, es zu erwaehnen.

So nun zum "eigentlichen" Thema: Es gibt schon gravierende Unterschiede ob man Angestellter oder Freiberufler ist und was die Firma fordert.
Ich habe in meiner letzten Firma, das UML erneut lernen duerfen. Ich habe es schon zweimal in der zwei Jahrzehnten davor gelernt.
Angewendet habe ich es als Freiberufler oder Angesteller jedoch nie. Einzige Ausnahme: Bei SAP Schulungen, bei der SAP.

Meine Sichtweise wird wohl auch etwas anderes sein, als die der meisten anderen hier, da ich seit 5 Jahren in den USA wohne und arbeite.

Re: Moderne Entwicklungsprozesse bei SAPlern

zzcpak hat geschrieben:Was mich wirklich mal sehr interessieren würde, wäre Testgetriebene-Entwicklung mit ABAP (Unit). Hab mal spaßeshalber probiert, habe aber irgendwie den Verdacht, dass ich da wirklich mit großen Mörsern auf Kakerlaken schieße. Spielt das überhaupt bei jemandem im Programmier-Alltag eine Rolle?

Mach mal ein Projekt in einer Bank oder in der Arzneimittelindustrie (hab ich beides hinter mir), da kriegst du ohne dokumentierte Tests und Progammdokumentation gar kein Programm ins Produktivsystem. UML wurde bei der Doku bisher nicht verwendet, weil es keiner lernen wollte. Ich kenne furchterregende (das meine ich ersthaft) Verzeichnisbäume mit tausenden Dokumenten drin, für deren Pflege man eine extra Anleitung braucht.

Re: Moderne Entwicklungsprozesse bei SAPlern

Meinen Diskussionsstil mag nicht jeder, das ist mir bekannt. Aber solange ich mit denen, mit denen ich bisher diskutiert habe, immer noch ein Bierchen trinken gehen kann, finde ich das ok Polarisation hat deutliche Vorteile.....

Unit605 hat geschrieben:

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.

Wenn Dein Bekannter bei der SAP im Entwicklungsbereich arbeitet, wird er, da er ja bei der SAP arbeitet, auch 100% recht haben. OK, damit kann ich nicht programmieren.

Du siehst den Unterschied zwischen meinem Satz und deinem?

Die Frage ist ja nicht, ob du nicht programmieren kannst, sondern ob du dir was abgeguckt hast von Leuten, die nicht programmieren konnten - und ob man sich die Frage stellen sollte, ob es nicht sinnvoll ist, alte/falsche Zöpfe abzuschneiden. Hey, ich hab das doch früher auch so gemacht, weil es alle gemacht haben. Bis ich in einen Laden kam, in dem es sowas wie Programmierrichtlinien nicht gibt und ich mich genau diesen Argumenten stellen musste. Sowas wie "Was soll die Beschreibung der Deklaration im Namen? Die Deklaration ist nur einen Doppelklick weit weg! Schreib rein, was IN der Tabelle ist, denn DAS herauszufinden, ist weit aufwendiger!"

Da kann man in sich gehen und sich fragen, ob man seine Gewohnheiten nicht einfach mal ändern sollte. Zumal gerade in höheren Sprachen die Datentypen eben nicht mehr nur elementar sind, sondern es zum Beispiel tiefe Tabellen gibt. Da komme ich in einen Konflikt, wenn ich über eine solche Tabelle loope und feststelle: Hey, das eine Element des Feldsymbols ist kein Feld, sondern eine Tabelle". Oder als was deklariere ich denn ein Feldsymbol, wenn erst zur Laufzeit bestimmt wird, auf was für eine Art Feld es zeigt?

Die SAP-Welt ist nicht schwarz und weiß, sie hat inzwischen beliebig viele Grautöne dazwischen.

Unit605 hat geschrieben:Dieses LS_/LT_Geschafel musst Du bei den meisten Firmen sogar anwenden und dafuer unterschreiben. Das sind die sogenannten Programmierrichtlinien.

Das macht sie nicht richtiger Ungarische Notation (wenn man sie denn haben will) sieht jedenfalls anders aus. Und wenn hier jemand schreibt, dass er das macht, weil er die Ungarische Notation gut findet, dann ist das so, als wenn er sagt "Ich kauf mir ein Segelboot, weil ich so gern Motorboot fahre". Und das nennst du dann ein "Totschlagargument"?

Unit605 hat geschrieben:Und Dein Beispiel LT_EKKO bedeutet in meine Programmen, dass es sich um eine interne Tabelle des Type EKKO handelt und ich brauche gar nicht nachzusehen, wie die Struktur aufgebaut ist, ich weiss es.

Naja, ok. Wenn du mit SELECT * arbeitest, mag das Sinn machen, aber ich weiß gar nicht mehr, wie lange das bei mir her ist, dass ich die EKKO in voller Breite selektiert habe. Ich ziehe mir, was ich brauche. Ein Bestellkopf, den du in einen BAPI wirfst, heißt dann konsequenterweise auch ls_bapimepoheader?

Unit605 hat geschrieben:So nun zum "eigentlichen" Thema: Es gibt schon gravierende Unterschiede ob man Angestellter oder Freiberufler ist

Ich habe in 15 Jahren noch kein Projekt erlebt, bei dem Freiberufler anderen Regeln unterliegen als Mitarbeiter.

Re: Moderne Entwicklungsprozesse bei SAPlern

Bei Deinem Diskussionstil habe ich persoenlich immer das Gefuehl, dass nur das gilt und richtig ist, was Du fuer gueltig und richtig haelst.

Bei Dir gibt es Schwarz und Weiss, wenn es Dir passt und es gibt Grautoene in dem Moment, wo es Dir passt.

Mein Kunden haben mich meisten nicht dafuer bezahlt, ob ich darueber nachdenke was sinnvoll fuer den Kunden ist oder nicht. Ich diskutiere auch nicht mit einem Kunden ob seine Programmierrichtlinien gut oder schlecht, richtig oder falsch sind. Ich unterschreibe diese Richtlinien und versuche mich daran zu halten.

Jetzt bist Du in einem Laden, oder warst in einem Laden, wo es anders gehandhabt wird, und nun versuchst Du jeden ABAP Developer von etwas zu ueberzeugen, was er wahrscheinlich in seinem ganzen Programmierleben braucht?

Und das Beispiel mit LT_EKKO war ein Beispiel aus dem Du wieder Schwarz und Weiss machst.

Ich habe in 15 Jahren noch kein Projekt erlebt, bei dem Freiberufler anderen Regeln unterliegen als Mitarbeiter.

Als Angesteller musste ich UML (wieder) lernen, als Freiberufler musste ich es nie fuer ein Projekt koennen oder lernen.
In beiden Faellen habe ich es nie anwenden muessen. (Ausser bei SAP Schulungen)