ein loop

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
35 Beiträge • Vorherige Seite 2 von 3 (current) Nächste
35 Beiträge Vorherige Seite 2 von 3 (current) Nächste

Re: ein loop

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
@Dele: Tuning ist immer gut und Kleinvieh macht aus Mist. Und wenn dann ein signifikanter Geschwindkeitszuwachs von 15% wie bei dir erreicht wird ist das nie zu verachten obwohl ich schätze, dass ihr diesen Aufwand nie betrieben hättet, wenn die Transaktion nur 10x am Tag aufgerufen worden wäre.

Aber nichtsdestotrotz möchte ich meine ursprüngliche Frage an adt auch an dich weitergeben. Hast du jemals erlebt, dass das Umstellen von Workarea/Kopfzeile auf Feldsymbol tatsächlich irgend etwas laufzeittechnisch Relevantes gebracht hätte?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: ein loop

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
black_adept hat geschrieben:@Dele: Tuning ist immer gut und Kleinvieh macht aus Mist. Und wenn dann ein signifikanter Geschwindkeitszuwachs von 15% wie bei dir erreicht wird ist das nie zu verachten obwohl ich schätze, dass ihr diesen Aufwand nie betrieben hättet, wenn die Transaktion nur 10x am Tag aufgerufen worden wäre.

Aber nichtsdestotrotz möchte ich meine ursprüngliche Frage an adt auch an dich weitergeben. Hast du jemals erlebt, dass das Umstellen von Workarea/Kopfzeile auf Feldsymbol tatsächlich irgend etwas laufzeittechnisch Relevantes gebracht hätte?
Ja, aber das waren meistens Auswertungen mit vielen Daten die in den Speicher geladen werden.
Wobei eine Applikation fällt mir ein, da waren User real betroffen: Übernehmen von Daten aus mehreren Datenquellen in eine bestehende Applikation. Das einzige Selektionskriterium war der Zeitraum. Die Standardapplikation hat hier je nach Datenmenge schon mal gemütliche 50% der Laufzeit "vertrödelt" indem es die Quellstrukturen mittels LOOP AT INTO analysiert hat. Nachdem wir eine eigene Funktion dafür gebaut haben (die zugegebenermaßen nun auch mehr Möglichkeiten bietet) wurde dieser Wert auf 5% maximal(!) gedrückt.

Beim Thema Performance bin ich der gleichen Meinnung wie Dele: Denke global, handle lokal.

Jedes Quentchen an Performanceverlust in einem "kleine" Programm kann bei entsprechend hoher Nutzung zu großen Problemen führen.
Wir haben knapp 5000 concurrent User auf unserem System und die meisten arbeiten über eine Art Portal-Oberfläche die die Arbeitsliste darstellt. Diese selektiert im Standard schon eine rießige Menge an Daten und wir müssen dann darauf aufbauen noch weitere selektieren und verarbeiten. Da machen wir in (leider) unregelmäßigen Abständen Laufzeitanalysen um Flaschenhälse aufzudecken. Meistens kommen da natürlich ungünstige DB-Zugriffe zu Tage, aber hin und wieder taucht da auch ein LOOP AT INTO auf, dem wir dann mit Field-Symbols auf die Sprünge helfen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: ein loop

Beitrag von Dele (Specialist / 307 / 4 / 47 ) »
@black_adept
In dem Buch "ABAP Performance Tuning" von Hermann Gahm heißt es sinngemäß zu diesem Thema:
- Lesender Zugriff: Feldsymbole bringen erst etwas, wenn mehr als 5.000 Byte bewegt werden.
- Ändernder Zugriff: Feldsymbole lohnen sich immer
Grundsätzlich: je größer die betroffenen Datenmengen, desto lohnender ist der Einsatz kopierfreier Techniken
Aber es gilt auch: je schneller die Rechner werden, desto geringer werden die Performance-Unterschiede. Dann fallen die "ganz langsamen" Programme erst wieder auf, wenn der Rechner an seine Grenzen kommt.

Und - ich gebe dir Recht -, als Entwickler kämpft man in der Regel nicht um Millisekunden. Ob ein einzelner LOOP mit Kopfzeile/Workarea oder mit Feldsymbolen ausgeführt wird, das merkt keiner. Und die größten Performancegewinne sind meistens bei Datenbankzugriffen zu erreichen.

Meine Illusion ist naiv. Das weiß ich. Doch wenn alle (nicht nur SAP) Entwickler Performance optimiert programmieren würden bzw. könnten (Zeit, Kompetenz), dann würden wir viel Strom und Geld sparen. Und beim Entwickeln ist ja vieles auch nur Gewöhnungssache.

Andererseits: Schlechte Software fördert Innovationen auf Hardwareseite.

In diesem Sinne kann also eigentlich jeder machen, was er will. :D

Re: ein loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
a-dead-trousers:
Sorry, aber vorallem den letzten Satz kann ich so nicht unkommentiert stehen lassen:
Beim Arbeiten mit Kopfzeilen, werden die Inhalte von der Tabelle in die Kopzeile KOPIERT. Genau gleich wie bei einer WORKAREA (Feldleiste).
Genau auf den Vergleich mit den Workareas habe ich mich auch bezogen, denn die sind ja die propagierte Alternative zu den Kopfzeilen. Man hat die Kopfzeilen ja nicht wegen der Performance deprecated.

Was die Feldsymbole und sonstigen Datenreferenzen angeht, so waren die gerade Thema in einem PN-Austausch zwischen Black Adept und mir. Was ich ihm dazu geschrieben habe, möchte ich auch an dieser Stelle nochmal zum besten geben:
Interne Tabellen über Feldsymbole zu manipulieren ist performant, mir aber dennoch unsymphatisch, weil man dabei sehr leicht aus dem Auge verlieren kann, wann, wo und warum Tabelleninhalte plötzlich mutieren. Im Quellcode ist es ein Segen, wenn man durch die 3000 Zeilen einfach nach dem Namen der internen Tabelle suchen kann und damit alle Stellen ausgeworfen bekommt, an denen damit etwas veranstaltet wird, wobei diejenigen, bei denen der Inhalt verändert wird, durch ein INSERT oder MODIFY explizit gekennzeichnet werden. Das macht das Verständnis und die Analyse insbesondere fremden Codes bedeutend einfacher - und wird von Feldsymbolen wirksam torpediert.

Datenreferenzen sind sowieso der effizienteste Weg sicherzustellen, dass kein anderer Programmierer nachvollziehen kann, was Dein Code da macht.
DELE:
Wir haben vor ein paar Monaten eine Eigenentwicklung getunt. Vorherige durchschnittliche Antwortzeit 510 Millisekunden, was ja eigentlich schon sehr gut ist. Danach 430 Millisekunden. Das hat kein Anwender bemerkt. Aber: die Anwendung hat pro Tag ca.230.000 Dialogschritte.
Ersparnis: ca. 18.400.000 Millisekunden = 18.400 Sekunden = 306 Minuten = 5,11 Stunden
5,11 Stunden klingt viel. Aber 230.000 Dialogschritte... wie viele User müssen das sein, um so viele Dialogschritte am Tag sinnvoll abwickeln zu können? Ich gehe davon aus, dass wir da von einer Organisationsgröße reden, bei der diese 5,11 Stunden absolute Peanuts sind. Sowas muss man immer im Verhältnis sehen. Ich hätte gerne im Monat 10.000 € mehr im Portemonnaie, aber wenn BMW im Monat 10.000 € einsparen würde, dann wäre das nicht mal einen Nebensatz wert.

Haubi:
Naja, die gibt es schon, allerdings sind das dann Programme, bei denen die Tabelle via Feldsymbol geändert wird. Da ist der Vorteil gegenüber einer Feldleiste und MODIFY erheblich.
Auch das halte ich in den allermeisten Fällen für grundfalsch. Dazu müsste nämlich der Anteil des ABAP-Interpreters an der Rechenzeit überhaupt nennenswert sein! Wo kommen denn die Antwortzeiten her, wenn ein Anwender auf "Sichern" klickt (oder sonst einen Schritt macht)? Zum allergrößten Teil von Datenbankanfragen. Heutzutage, da die SAP-Server meist nicht mehr im eigenen Haus stehen, kommen noch Leitungslatenzen als zweiter, durchaus gravierender Faktor hinzu (verschärft von in den Leitungen sitzenden Firmenfirewalls mit ihrer Deep Packet Inspection). Der Anteil des ABAP-Interpreters an der Gesamtantwortzeit ist minimal. Je nach Anwendung wird der irgendwo im einstelligen Prozentbereich liegen. Und wenn man jetzt seine internen Tabellenzugriffe (die ja selbst wiederum nur einen Teil der Interpreter-Rechenzeit ausmachen, sagen wir mal 50%) auf Feldsymbole umstellt, dann hat man von den 5% Interpreterrechenzeit einen Anteil von 2,5% optimiert. Der Optimierungserfolg beträgt, sagen wir, 30%. Also sind diese 2,5% der Gesamtantwortzeit des Systems um 30% besser geworden und machen jetzt nur noch 1,7% der Gesamtantwortzeit des Systems aus.

Damit soll man was bewegen können? Das ist doch ein Witz! Der Preis, den man dafür bezahlt, ist der aus den oben geschilderten Gründen wesentlich schlechter nachvollziehbare Code. Die Rechnung geht nicht auf!

Wenn man ein wirklich lahm laufendes ABAP-Programm hat, bei dem auf das ABAP-Coding tatsächlich wesentliche Teile der Verzögerungen entfallen, dann liegt das in aller Regel an mies programmierten Datenbankanfragen (Index nicht oder schlecht genutzt oder dieselbe Datenbankanfrage 10000x gestellt, anstatt zu puffern) oder opulenter Umgang mit ABAP-Befehlen wie SORT (die sich bei durchdachterer Programmierung immer auf ein performancetechnisch irrelevantes Maß reduzieren lassen sollten). Allenfalls kann man noch was rausholen, indem man interne Tabellen ordentlich sortiert und suchoptimiert darauf zugreift. Habe allerdings noch keinen Berater gesehen, der das macht und ärgere mich fast, dass deren Programme trotzdem so performant zu laufen pflegen, dass keiner was sagt.

Und verglichen mit all diesen Performanceschandtaten soll man was an der Performancefront etwas bewegen können, indem man Feldleisten anstelle von Workareas (egal ob Kopfzeile oder nicht) verwendet? Also mal ernsthaft...

a-dead-trousers:
Die Standardapplikation hat hier je nach Datenmenge schon mal gemütliche 50% der Laufzeit "vertrödelt" indem es die Quellstrukturen mittels LOOP AT INTO analysiert hat. Nachdem wir eine eigene Funktion dafür gebaut haben (die zugegebenermaßen nun auch mehr Möglichkeiten bietet) wurde dieser Wert auf 5% maximal(!) gedrückt.
Aber garantiert nicht dadurch, dass ihr den LOOP AT INTO durch einen LOOP AT ASSIGNING ersetzt habt. Ich behaupte, wenn ihr nur das gemacht hättet, wäre das Ergebnis nicht wahrnehmbar gewesen. Das hättet ihr unter Ulk verbuchen können.

a-dead-trousers:
Beim Thema Performance bin ich der gleichen Meinnung wie Dele: Denke global, handle lokal.
Das Mantra ist richtig, hat aber eine Dimension, die Du anscheinend nicht im Auge hast: Die Wartbarkeit des Codes. Jeder Schritt hin zu einem schlechter nachvollziehbaren Code kostet einen Preis, der nichts mit Performance zu tun hat, gleichwohl jedoch ganz erheblich ist. Für einen Performancegewinn, der so lächerlich ist wie Feldsymbol statt Workarea nebst MODIFY, in Kauf zu nehmen, dass ein anderer Entwickler, der den Code vielleicht mal warten muss, nicht mehr mit wenigen Handgriffen nachvollziehen kann, wo der Inhalt dieser internen Tabelle genutzt wird und wo er insbesondere verändert wird, ist nicht zu rechtfertigen. Ein einziger Bug, der einem durch solch unnötig erhöhte Komplexität reinrutscht, kann ganz locker mehr kosten als alles, was diese Minimalstoptimierung in 20 Jahren an gesparter Arbeitszeit einbringen würde!

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
user2008


Re: ein loop

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
DeathAndPain hat geschrieben:Interne Tabellen über Feldsymbole zu manipulieren ist performant, mir aber dennoch unsymphatisch, weil man dabei sehr leicht aus dem Auge verlieren kann, wann, wo und warum Tabelleninhalte plötzlich mutieren. Im Quellcode ist es ein Segen, wenn man durch die 3000 Zeilen einfach nach dem Namen der internen Tabelle suchen kann und damit alle Stellen ausgeworfen bekommt, an denen damit etwas veranstaltet wird, wobei diejenigen, bei denen der Inhalt verändert wird, durch ein INSERT oder MODIFY explizit gekennzeichnet werden. Das macht das Verständnis und die Analyse insbesondere fremden Codes bedeutend einfacher - und wird von Feldsymbolen wirksam torpediert.
DeathAndPain hat geschrieben:
a-dead-trousers hat geschrieben:Beim Thema Performance bin ich der gleichen Meinnung wie Dele: Denke global, handle lokal.
Das Mantra ist richtig, hat aber eine Dimension, die Du anscheinend nicht im Auge hast: Die Wartbarkeit des Codes. Jeder Schritt hin zu einem schlechter nachvollziehbaren Code kostet einen Preis, der nichts mit Performance zu tun hat, gleichwohl jedoch ganz erheblich ist. Für einen Performancegewinn, der so lächerlich ist wie Feldsymbol statt Workarea nebst MODIFY, in Kauf zu nehmen, dass ein anderer Entwickler, der den Code vielleicht mal warten muss, nicht mehr mit wenigen Handgriffen nachvollziehen kann, wo der Inhalt dieser internen Tabelle genutzt wird und wo er insbesondere verändert wird, ist nicht zu rechtfertigen. Ein einziger Bug, der einem durch solch unnötig erhöhte Komplexität reinrutscht, kann ganz locker mehr kosten als alles, was diese Minimalstoptimierung in 20 Jahren an gesparter Arbeitszeit einbringen würde!
Ich glaube schön langsam verstehe ich dein Problem:
Du hast nicht gelernt deine Programme in kleine Happen aufzuteilen. Wenn ich ein (Unter-)Programm mit mehr als 100 Zeilen Programmcode sehe, überleg ich mir bereits ob nicht ein Refactoring notwendig wäre. Ganz zu schweigen von 3000 Zeilen. Gut, Legacy Code wird man nicht von heute auf morgen optimieren können. Da gebe ich dir auch recht, dass es in diesem Fall schon Sinn macht zu sehen an welchen Stellen wirklich etwas mit einer Tabelle geschieht. Aber bei Neuentwicklungen sollte man sich dann schon die Zeit nehmen um die Klassen so zu gestalten, dass aus den Namen (oder zumindest der Beschreibung) hervorgeht, was deren Methoden bewirken. Innerhalb der Methoden kann man dann den Code nach herzenslust optimieren, ohne Gefahr zu laufen, die Lesbarkeit über den kompletten Programmablauf zu verlieren.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Richtig. Wer mit "Suchen" die Verwender ermittelt, macht was falsch. Wer einmal gescheit modularisierte Anwendungen zu schätzen gelernt hat, der will so 3000-Zeilen-Monster nicht mehr.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ich glaube schön langsam verstehe ich dein Problem:
Du hast nicht gelernt deine Programme in kleine Happen aufzuteilen.
Da liegst Du deutlich falsch, ebenso wie mit Deiner Annahme, das dies in "Legacy Code" nicht üblich sei. "Strukturierte Programmierung", die ja landläufig als Vorgänger von OO gilt, hat nicht ohne Grund diesen Namen. Ob Du eine FORM oder eine Methode machst ist nebensächlich. In beiden Fällen strukturierst Du Dein Programm. Und glaub mir, das mache ich seit jeher, und ich behaupte, in deutlich überdurchschnittlicher Qualität (insbesondere was die Dokumentation meiner Unterroutinen angeht).

Dass man dabei schlampen und allen Code ohne Unterroutinen in einen Haufen schmeißen kann, ist klar. Das kannste in Klassen ebenso tun wie in herkömmlichem Code. Wobei mir gerade in ABAP an Klassen und Methoden die Art der Quelltextgestaltung deutlich missfällt. Bei einer FORM hat Du am Anfang der Form ganz klar im Quelltext die Parameter zu stehen (optimalerweise mit Typisierung). Bei einer lokalen Methode schaust Du in die Methode und siehst erst mal gar nicht, was für Parameter es überhaupt gibt, denn die stehen am anderen Ende des Quellcodes in der Definition. Besonders bescheuert wird es dann, wenn man Methoden "definiert", ohne sie an der Stelle wirklich zu definieren, einfach nur um bürokratischen Forderungen der Sprache zu genügen. In ABAP nennt sich das dann DEFINITION DEFERRED.

Bei globalen Klassen ist es besser, weil man in der SE24 die Parameter immer oben zu stehen hat. Wobei mir bei der SE24 der Inputmedienbruch nicht gefällt. Quellcode will ich runterschreiben können und nicht gezwungen sein, ständig zur Maus zu greifen und mich durch irgendwelche Masken zu klicken, weil andere Ecken des Quellcodes sich per Tastatur nicht erreichen lassen.

Allerdings hat eine zu feine Segmentierung in Objekte, Methoden usw. auch einen gravierenden Nachteil: Man muss genau wissen, was diese Elemente tun. Es muss also bei jeder einzelnen Methode und Klasse üppigst dokumentiert werden, wie damit umzugehen ist. Und Hand auf's Herz: das macht kein Schwein. Wieviele Deiner Methoden oder Klassen (oder Funktionsbausteine) haben eine umfassende Online-Dokumentation? Üblich ist, überhaupt keine zu machen. Und damit führst Du die Idee der Kapselung nämlich ad absurdum. Denn selbst im übelsten Spaghetticode gilt, dass da nur Befehle drinstehen, die zum ABAP-Befehlssatz gehören. Damit kennt man ihre Funktionsweise (oder kann sie notfalls nachlesen) und kann sich mit Debugger und Spucke da durchwursteln.

Wenn Du aber eine Kette von Methodenaufrufen hast, bei denen Du noch nicht mal weißt, was die Idee hinter dem zugehörigen Objekt ist, geschweige denn, was das Sollverhalten der gut gekapselten Methode ist, da keinerlei Online-Doku existiert, dann kommst Du ganz schnell in eine Situation, in der Du im Prinzip keine Chance hast. Und das ist die Realität. Gut online dokumentierte Klassen und Methoden trifft man in der Realität so gut wie gar nicht an. Bei Forms ist es zugegebenermaßen nicht viel anders. Aber aufgrund der schwächeren Kapselung und besser lesbaren (da nicht über den ganzen Code verstreuten) Definition kann man sich bei Forms die Funktionalität besser selber herleiten.

Wie hat mal einer so schön gesagt: "I don’t know the answer but I do know that debugging what happens after pressing a command in VA01 is easier to follow than the equivalent in ME21N. Or is that just because I am an OO novice?"

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
user2008


Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ohweh. Ich hatte mich auf ein entspanntes WE gefreut und dann lese ich sowas.

Dass eine Methodendefinition Teil der Klassendefinition ist, ist richtig (im Sinne von "gewollt"). Nur deshalb prüft z. B. die Syntaxprüfung die Typen der Parameter. In Funktionsbaustein-Aufrufen findet diese Prüfung nicht statt, aus genau diesem Grund.

Es steht dir frei, Eclipse oder den Quelltext-Editor mit Splitscreen zu nutzen, um weniger klicken zu müssen. FORMs sind schon deshalb doof, weil man sie nicht von außen ansprechen kann (bzw. soll).

Zum Verständnis bzgl. Debuggen: OO ist eine "Abstraktionsschicht", die Vieles ermöglicht, was ohne sie nicht umsetzbar wäre. Das bedeutet aber auch, dass Menschen, die damit umgehen, ein gewisses Abstraktionsvermögen besitzen und etwas mehr können, als Kommandos hintereinander zu schreiben. Und dass man sich eben mit dieser Abstraktion auch beschäftigt. Man kann eben nicht mehr so einfach drauflos debuggen nach dem Motto "ich sehe ja, was passiert".

Wie Daniel es hier mal schrieb: Ein wichtiger Vorteil von ABAP ist, dass es sich liest wie englische Prosa, so dass es jeder Idiot verstehen kann. Um es nochmal deutlich zu sagen: Die Zeiten sind vorbei!! Das war ein Vorteil für den Kleinkram, den man zu ABAP-Anfangszeiten schrieb. Aber jetzt, wo komplexe Anwendungen in ABAP entstehen (und das ist ja schon eine Weile so), kommt man damit nicht weiter, wenn man das noch wartbar betreiben will.

Ich bin gerade an der Entwicklung einer hoch komplexen Anwendung beteiligt, die intensiv diese Abstraktionsmechanismen nutzt und ich bin dankbar dafür, viele kleine Einheiten zu haben, die in sich selbstständig funktionieren und die miteinander über definierte Schnittstellen kommunizieren.

Ja, die "F5 im Debugger"-Fraktion muss sich weit recken, um das zu verstehen. Aber es lohnt sich - schon deshalb, weil wir extrem viel Coding durch Abstraktion einsparen, weil das vorhandene eben durch diese Abstraktion sehr multifunktionell wird.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:[...] Bei Forms ist es zugegebenermaßen nicht viel anders. Aber aufgrund der schwächeren Kapselung und besser lesbaren (da nicht über den ganzen Code verstreuten) Definition kann man sich bei Forms die Funktionalität besser selber herleiten.[...]
???
Bei Klassen stehen alle Methodendefinitionen zusammen und bei den Methoden stehen dann auch alle ihre Parameter. Somit ist hier tatsächlich alles an einem Fleck untergebracht was man hoffentlich zum Verstehen dess Sinn und Zwecks einer Methode benötigt.
Bei FORMs sind zwar Definition und Implementierung nicht getrennt - aber dafür verteilen sich die FORMS selber über den gesamten Quellcode. Wenn ich also nur die Modularisierungseinheit FORM und METHOD betrachte sind alle Informationen gleich gut oder schlecht zu überschauen. Aber wenn ich die Gesamtheit der Methoden / FORMS anschaue um einen Überblick zu erhalten ist es bei den Klassen deutlich übersichtlicher.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ihr habt beide recht - er bemängelt ja gerade, dass die Methodenschnittstelle so weit weg von der Implementierung ist. Darum kann man die Signatur in der SE24 ja einblenden.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Ohweh. Ich hatte mich auf ein entspanntes WE gefreut und dann lese ich sowas.
ralf.wenzel hat geschrieben:Dass eine Methodendefinition Teil der Klassendefinition ist, ist richtig (im Sinne von "gewollt"). Nur deshalb prüft z. B. die Syntaxprüfung die Typen der Parameter. In Funktionsbaustein-Aufrufen findet diese Prüfung nicht statt, aus genau diesem Grund.
Du meinst vielleicht das Richtige - aber so ist das falsch. Die Prüfung findet schon statt - aber erst zur Laufzeit weil ABAP nicht zwischen dynamischen und statischen Funktionsaufrufen unterscheidet.
ralf.wenzel hat geschrieben:Zum Verständnis bzgl. Debuggen: OO ist eine "Abstraktionsschicht", die Vieles ermöglicht, was ohne sie nicht umsetzbar wäre. Das bedeutet aber auch, dass Menschen, die damit umgehen, ein gewisses Abstraktionsvermögen besitzen und etwas mehr können, als Kommandos hintereinander zu schreiben. Und dass man sich eben mit dieser Abstraktion auch beschäftigt. Man kann eben nicht mehr so einfach drauflos debuggen nach dem Motto "ich sehe ja, was passiert".

Wie Daniel es hier mal schrieb: Ein wichtiger Vorteil von ABAP ist, dass es sich liest wie englische Prosa, so dass es jeder Idiot verstehen kann. Um es nochmal deutlich zu sagen: Die Zeiten sind vorbei!! Das war ein Vorteil für den Kleinkram, den man zu ABAP-Anfangszeiten schrieb. Aber jetzt, wo komplexe Anwendungen in ABAP entstehen (und das ist ja schon eine Weile so), kommt man damit nicht weiter, wenn man das noch wartbar betreiben will.
Ich bin gerade an der Entwicklung einer hoch komplexen Anwendung beteiligt, die intensiv diese Abstraktionsmechanismen nutzt und ich bin dankbar dafür, viele kleine Einheiten zu haben, die in sich selbstständig funktionieren und die miteinander über definierte Schnittstellen kommunizieren.
Ja, die "F5 im Debugger"-Fraktion muss sich weit recken, um das zu verstehen...
Was für ein elitärer und selbstbeweihräuchernder Humbug - ein neuer Höhepunkt deiner Postings, Ralf.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
Unit605DeathAndPainMurdock

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: ein loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Es steht dir frei, Eclipse oder den Quelltext-Editor mit Splitscreen zu nutzen
Das tue ich auch, nachdem mir die SAP mit Release 7.40 meinen geliebten Backend-Editor final abgekniffen hat (ja, ich weiß, aber wenn man die ganzen geisteskranken Hotkeys verinnerlicht hat, kann man damit irrsinnig schnell arbeiten und schlägt locker die Mausmarkier-Frontendfraktion). Da ich mich also ohnehin umgewöhnen musste, habe ich gesagt, ok, dann mache ich gleich den großen Schritt und setze direkt auf den allerneuesten Sch.... Habe es auch nicht bereut. Eclipse ist cool, wenn man sich dran gewöhnt hat.
FORMs sind schon deshalb doof, weil man sie nicht von außen ansprechen kann (bzw. soll).
Und bei privaten Methoden ist das anders? Die wenigsten Unterroutinen in einem strukturiert aufgebauten Programm sollen von außen ansprechbar sein. Soweit dies gewünscht ist, nimmt man bei klassischem Code Funktionsbausteine.
Zum Verständnis bzgl. Debuggen: OO ist eine "Abstraktionsschicht", die Vieles ermöglicht, was ohne sie nicht umsetzbar wäre. Das bedeutet aber auch, dass Menschen, die damit umgehen, ein gewisses Abstraktionsvermögen besitzen und etwas mehr können, als Kommandos hintereinander zu schreiben. Und dass man sich eben mit dieser Abstraktion auch beschäftigt.
Soweit die Theorie. Die funktioniert auch hervorragend, wenn Du das Programm selber geschrieben hast, denn dann kennst Du alle Ideen und Konzepte und kennst genau das Sollverhalten all Deiner Objekte und Methoden.

Aber wie sieht es aus, wenn Du fremden Code warten sollst? Da hast Du dann auch ein Sammelsurium von Klassen, Objekten und Methoden und keinen Schimmer, wozu sie da sind. Und genau hier liegt das Problem: Abstraktion funktioniert nur, solange man sie kennt. Wenn Du nicht weißt, was da abstrahiert wurde, weil die Ideen und Konzepte von jemand anderem sind und dieser jemand wie immer und überall schlecht dokumentiert hat, dann stehste da! Dann hast Du gar keine andere Chance, als mit dem Debugger ranzugehen und zu analysieren, was sein Code da macht, damit Du Dir eine Vorstellung vom Sollverhalten erschließen kannst. Und das ist bei solch Code halt nur sehr schwer möglich.

Wie Du schon sagst, liest sich solch Programm im Prinzip wie Prosa. Die "Befehle", die es nutzt, sind selbstgebaut, denn es handelt sich um Methoden. Und das bedeutet für den Außenstehenden, dass er ein Programm warten soll, bei dem er die Befehle nicht kennt, aus denen es besteht. Also muss er diese einzeln analysieren. Das ist, als ob Du bei einem ABAP-Programm den Kernel disassemblieren oder debuggen müsstest, um Dir die Funktionsweise der ABAP-Befehle zu erschließen.

Besondern schlimm wird es, wenn etwas nicht wie vorgesehen funktioniert. Eine Methode sollte sich von Deinem Verständnis (auch ihrer Benamung) her in gewisser Weise verhalten, aber das tut sie nicht. Dementsprechend läuft auch das ganze Programm nicht wunschgemäß. Irgendwo liegt also ein Bug vor. Jetzt ist die Frage: Sitzt der Bug in der Methode und wäre behoben, wenn sie sich so verhalten würde, wie Du es erwartest, oder ist die Methode in Ordnung und Dein Verständnis ihrer Funktionsweise und Sollverhaltens falsch, und der Bug liegt ganz woanders? Viel Spaß beim Rausfinden!
Ich bin gerade an der Entwicklung einer hoch komplexen Anwendung beteiligt, die intensiv diese Abstraktionsmechanismen nutzt und ich bin dankbar dafür, viele kleine Einheiten zu haben, die in sich selbstständig funktionieren und die miteinander über definierte Schnittstellen kommunizieren.
Dann mach Dir doch mal den Spaß und versetze Dich in die Situation eines externen Beraters (oder Deines Nachfolgers, nachdem Du die Firma verlassen hast). Tausch die Aufgaben mit einem Deiner Kollegen, so dass Du vor den von Dir genannten vielen kleinen Einheiten stehst, freilich seinen und nicht Deinen eigenen, und rausfinden darfst, wofür sie stehen und was ihr genaues bestimmungsgemäßes Sollverhalten ist (erforderlich, um zwischen Bug und Feature unterscheiden zu können und generell zu verstehen, wie das Programm arbeitet). Dabei darfst Du ihn nicht fragen und Dich nicht an etwaiger Papier- oder Dateidoku bedienen, sondern musst am Quellcode bleiben.

Wenn er lehrbuchmäßig gearbeitet hätte, wäre das kein Problem. Da wäre an jeder Klasse eine Klassendokumentation, an jeder Methode eine Methodendokumentation, sie alle würden die entsprechenden abstrakten Gedanken und Konzepte beschreiben, und man könnte Sollverhalten und Verwendungsweise dieser Elemente einfach nachlesen und sich zurechtfinden. SAP bietet ja üppig Ablagemöglichkeiten für derartige Texte.

Aber ohne zu wissen, welchen Kollegen Du Dir für dieses Experiment aussuchst, behaupte ich: Da ist wenig bis gar nix. Wenn Du Glück hast, stehen mal drei Zeilen Text in einer Klassendoku, aber spätestens auf Methodenebene ist keinerlei Online-Doku mehr vorhanden. Das ist ja sogar beim Original-SAP-Quellcode nicht anders. Und genau das ist die Stelle, an der Du Dir die Karten legst und an der die Abstraktion vom Segen zum Fluch wird.

Innerhalb eines Beratungshauses hat man in der Regel noch eine gewisse Doku, in Dateien und teils auch auf Papier. Da gibt es einen Projekt-Blueprint, gerne mit dreistelliger Seitenzahl, und da mag es auch Word-Dokumente für die einzelnen Teilmodule des Konzeptes geben, in denen die Klassen genannt sind und deren Funktionsweise geschildert wird. So geht z.B. auch die SAP vor; das ist der Grund, weshalb die ihren eigenen Code noch warten können. Aber sobald ein Außenstehender da was tun soll, ist er ganz bitterlich aufgeschmissen. Und das ist die große Kehrseite der Objektorientierung.

Im übrigen ist es durchaus nicht so, dass alle Programmieraufgaben heute Großprojekte sind, die ohne entsprechende Abstraktion nicht zu handhaben sind. Im Gegenteil behaupte ich, der Beratungsalltag besteht aus vergleichsweise kleinen Projekten. Da braucht man hier mal einen Report, dort mal einen User Exit, um das Systemverhalten nach Kundenwunsch anzupassen. Und in dem Bereich kommt man prozedural bedeutend schneller zum Ziel, und zwar unter Erzeugung eines Codes, der mitnichten schlechter zu warten ist als OO, ganz im Gegenteil!

Für richtige Mammut-Großprojekte mag OO durchaus richtig sein, kombiniert mit einer disziplinierten, ausführlichen Dokumentation (die - zusätzlich zur üblichen Dateidoku - online direkt an den jeweiligen OO-Objekten erfolgen sollte, außer ich verfolge die Strategie, den Kunden durch Vorenthalten brauchbarer Onlinedoku an mein Beratungshaus zu binden, weil niemand sonst das warten kann). Aber für die meisten Entwickler sind solche Großprojekte nicht der Alltag.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
user2008Unit605


Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Mein lieber black_adept.

Ich habe von der Syntaxprüfung geschrieben. Dass sowas zur Laufzeit knallt, ist doch klar.

Zu deinem anderen Hinweis: Was genau ist fachlich an meinem Posting falsch? Ist OO keine weitere Abstraktionsebene? Muss man nicht, wenn man die ME21N debuggen will, sich mit den Objekten und deren Beziehungen befassen? Ist es nicht das, was der OP als letzten Satz beschrieb, wenn er sagt VA01 sei einfacher zu debuggen? Ist es nicht so, dass prozedural denkende Programmierer genau diese Probleme haben? Ist es nicht so, dass das Niveau, das von einem Entwickler erwartet wird, durch OO deutlich steigt?

Das mag alles unangenehm sein, aber es ist vor Allem eines: Wahr! Davor die Augen zu verschließen, bringt nichts. Wenn man das tut und sich in OO nicht reinkniet, guckt man dumm, wenn man vor einem EWM sitzt, in dem auch die Persistenz mit OO abgebildet ist (BOPF). Von einem S/4 will ich da gar nicht erst reden.

Es ist mir egal, wenn ich unangenehme (oder wie du es nennst: elitäre) Sachen schreibe -- solange sie nicht falsch sind.... ;)

Und an DeathAndPain:

Natürlich hängt die Qualität einer Entwicklung auch an ihrer Dokumentation. Darum ist - eben aufgrund der höheren Abtraktionsebene - die Doku auch besonders wichtig und sollte nicht einfach weggelassen werden. Sie ist Bestandteil des Codings und ich würde keinen Berater wegschicken, ohne dass er sein Coding gescheit dokumentiert hat. Dass das oft nicht geschieht, liegt daran, dass viele noch im "Steht doch eh alles im Coding"-Modus sind, was bei OO eben so nicht mehr stimmt. Der Vorteil dabei ist: Es fordert zum Dokumentieren auf, man darf den Ruf halt nicht überhören. Undokumentiertes Coding würde ich nicht in mein SAP System lassen, denn das Wissen über die Prozesse, das in den Köpfen der Mitarbeiter ist, ist wertlos für das Unternehmen.

Leider, und das finde ich ganz, ganz übel und wurde von mir mit Horst Keller diskutiert, fehlt in Eclipse eine übersetzbare, versionierte Dokumentationsmöglichkeit am Objekt wie die SE80 sie bietet.

Ich habe übrigens schon viele Fremdanwendungen gewartet, und das ist bei den 3.000-Zeilen-Monstern, in denen ein "X" vom Himmel fällt und was tut, auch nicht einfacher.



Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Natürlich hängt die Qualität einer Entwicklung auch an ihrer Dokumentation. Darum ist - eben aufgrund der höheren Abtraktionsebene - die Doku auch besonders wichtig und sollte nicht einfach weggelassen werden. Sie ist Bestandteil des Codings und ich würde keinen Berater wegschicken, ohne dass er sein Coding gescheit dokumentiert hat.
In der Praxis läuft es aber in aller Regel anders.
Der Vorteil dabei ist: Es fordert zum Dokumentieren auf, man darf den Ruf halt nicht überhören.
Gut dokumentieren war schon zu allen Zeiten ratsam und angesagt. Die Tatsache, dass man bei herkömmlichem Code ohne Doku noch eine Chance hat und bei OO nicht, soll jetzt ein Vorteil von OO sein?!? Das finde ich doch eine sehr verquere Logik.
Leider, und das finde ich ganz, ganz übel und wurde von mir mit Horst Keller diskutiert, fehlt in Eclipse eine übersetzbare, versionierte Dokumentationsmöglichkeit am Objekt wie die SE80 sie bietet.
Die kommt ja vielleicht noch. Der Self-Updater von Eclipse findet ja alle paar Tage was Neues. Wobei kürzlich (im Rahmen einer neuen Version) allerdings nicht etwas Neues gekommen, sondern etwas verschwunden ist. In der Vergangenheit konnte ich über das Menü Navigate -> Open Others direkt in die Pflege der Texte zum Programm abspringen. Dieser Menüpunkt ist jetzt in Oxygen nicht mehr da. Weiß Du zufällig, wo er geblieben ist?
Ich habe übrigens schon viele Fremdanwendungen gewartet, und das ist bei den 3.000-Zeilen-Monstern, in denen ein "X" vom Himmel fällt und was tut, auch nicht einfacher.
Da sind wir deutlich unterschiedlicher Meinung.

Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Nein, kommt nicht. Zumindest nicht in absehbarer Zeit, sagt Horst.

Und ja, dass OO-Anwendungen ohne Doku fast wertlos sind, ist gut, wenn es zu mehr Doku führt. Das ist keine schräge Begründung, sondern Pragmatismus. Ich kann undokumentierte Programme nicht leiden, egal ob 3.000-Zeilen-Monster oder OO-Anwendung. Und ich wünschte, die SAP-Kunden machten mehr Druck dahingehend, dass die SAP wieder alle Entwicklungsobjekte dokumentiert. Die ganz alten SAP-Funktionsgruppen sind oft die am Besten dokumentierten Objekte überhaupt.

Ich weiß, dass es in der Regel anders läuft und das muss sich ändern. Die Qualitätsansprüche sind in keinem Industriezweig so niedrig wie in der SAP-Entwicklung. Da reicht ein "läuft, hab ich exemplarisch ausprobiert" zur produktiven Nutzing. Jede Schraube, die derselbe Kunde in der Produktion einsetzt, unterliegt härteren Kriterien.



Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

1
Antw.
721
Views
4
Antw.
3450
Views
LOOP in einem LOOP
von Bjuti » 10.09.2013 15:18 • Verfasst in ABAP® für Anfänger
39
Antw.
7075
Views
Loop
von Kai999 » 27.07.2017 16:15 • Verfasst in ABAP® für Anfänger
52
Antw.
9281
Views
LOOP AT
von cuncon » 01.02.2018 09:28 • Verfasst in ABAP® für Anfänger
7
Antw.
2262
Views
Loop-Problem
von TobiB » 17.12.2007 13:15 • Verfasst in ABAP® Core

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140