Neue Themen als SAP Entwickler
Mir sind in den letzten Wochen noch zwei Gründe aufgefallen, warum ich Unit-Test mache:
1) Wenn man länger nicht an seinem Quellcode war und nach 1 Jahr wieder was anpassen soll, kann man prüfen, ob noch alles läuft. Häufig gibt es andere Entwickler die "Korrekturen" machen und damit vielleicht neue Fehler einbauen. Wenn man nun selbst was anpasst und es läuft nicht, war man der letzte "Dumme", der am Coding was geändert hat.
2) Ich hatte es jetzt bei zwei Kunden, die auf dem E-System keine Datenpflege zulassen. Sprich, man muss immer seine Entwicklung erst ins Folgesystem (z.B. Q-System ) transportieren (lassen!). Mit den Unit-Tests konnte ich aber auf dem E-System wenigstens vortesten.
--
Und nein, nicht für jeden Fall lege ich einen Unit-Test an. Aber für neuralgische Bereiche, macht das schon Sinn.
1) Wenn man länger nicht an seinem Quellcode war und nach 1 Jahr wieder was anpassen soll, kann man prüfen, ob noch alles läuft. Häufig gibt es andere Entwickler die "Korrekturen" machen und damit vielleicht neue Fehler einbauen. Wenn man nun selbst was anpasst und es läuft nicht, war man der letzte "Dumme", der am Coding was geändert hat.
2) Ich hatte es jetzt bei zwei Kunden, die auf dem E-System keine Datenpflege zulassen. Sprich, man muss immer seine Entwicklung erst ins Folgesystem (z.B. Q-System ) transportieren (lassen!). Mit den Unit-Tests konnte ich aber auf dem E-System wenigstens vortesten.
--
Und nein, nicht für jeden Fall lege ich einen Unit-Test an. Aber für neuralgische Bereiche, macht das schon Sinn.
Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
ralf.wenzel
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Funktionsgruppen sind wenn schon eher Klassen mit Vererbung. Schon aufgrund des globalen Sichtbarkeitsbereiches im TOP Include. Nun ja mehr können Funktionsgruppen nicht. Das die UI an der Logik gekoppelt ist, ist eher ein Nachteil denn ein Vorteil. Deswegen sollte man heutzutage nur noch dann einen FM schreiben, wenn man UI braucht. Für alles andere sollten ausschließlisch Klassen benutzt werden.DeathAndPain hat geschrieben: ↑04.09.2024 11:22Tatsächlich würde ich Klassen nicht mit Formroutinen vergleichen, sondern mit Funktionsgruppen. Wenn man genau darüber nachdenkt, stellt man fest, dass eine Funktionsgruppe von der Funktionalität her nichts anderes ist als eine abstrakte Klasse ohne Vererbung und separate Interfaces. Die darin enthaltenen Funktionsbausteine sind die Methoden, und die globalen Variablen der Funktionsgruppe sind die Attribute. Womit einmal mehr das deutlich wird, was ich immer wieder gerne betone: Attribute sind nichts anderes als globale Variablen mit all ihren Nachteilen und nach meiner Überzeugung der Hauptgrund dafür, dass ABAP OO-Programme so oft viel schlechter verständlich sind als herkömmliche prozedurale Programme. Durch die Attribute ist das Verhalten der Methoden nicht mehr durch das definiert, was man den Methoden über ihre Schnittstelle übergibt, und eine Methode kann sich mal so und mal völlig anders verhalten, je nachdem, was eine völlig andere Methode irgendwann früher mal irgendwo in einem Attribut abgelegt hat. Wer die Klasse nicht sehr gut kennt (bzw. sie gerade erst zu begreifen versucht), bekommt hier gerne mal die größten Verständnisprobleme.
Vom Leistungsumfang sind Funktionsgruppen und statische Klassen ohne Vererbung also gleich. Wenn man das Detail hinzunimmt, dass Funktionsgruppen eigene Dynpros haben und RFC-tauglich sein können, können sie in bestimmten Hinsichten sogar ein bisschen mehr. Allein die Schönheit der Aufrufe (insbesondere funktionaler Aufrufe und Aufrufe mit Inline-Deklarationen) rechtfertigt es in meinen Augen aber durchaus, dennoch auf abstrakte Klassen zu setzen. Meine Programme sind deutlich besser lesbar geworden, seit ich das mache - was das Handhaben höherer Abstraktionsgrade erleichtert.
Und da kommt automatisch eine Antwort für den Thread-Ersteller. Das wichtigste Thema, was ich vermisse ist "Gute Kenntnisse in Softwarearchitektur". Da gehört eine Menge dazu.
Folgende Benutzer bedankten sich beim Autor gtoXX für den Beitrag:
ralf.wenzel
"Code lügt nicht ^^"
Also das Performanceargument trifft schon mal gar nicht zu. Warum gibt es Instanziierung ? Weil ein Objekt zu seiner Laufzeit von einem Objekt gleichen Typs ersetzt werden kann. Das kann ein FM nicht. Die auch ganz furchtbar sind.DeathAndPain hat geschrieben: ↑05.09.2024 10:41
Wie von black_adept schon eingewendet habe ich explizit "abstrakte Klassen" gesagt, also Klassen, die nicht instanziierbar sind. Bei solchen Klassen hast Du nicht mehrere Objekte für mehrere Belege (oder was auch immer). Natürlich kann man mit Instanziierung von Objekten Sachen machen, die über Funktionsgruppen hinausgehen. Das habe ich nie bestritten. Allerdings habe ich auf den Umstand hingewiesen, dass der Löwenanteil der Klassen, die ich von anderen Entwicklern zu sehen bekomme, nur genau einmal instanziiert wird. Dann aber ist die Instanziierung nutzlos und legt nur eine überflüssige Abstraktionsebene drüber, die die Performance senkt und das Programm schlechter lesbar macht.
Forms haben zusätzlich den Nachteil, das ein USING gleichzeitig ein CHANGING ist und es keine Returnparameter gibt.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Das stimmt nicht so ganz. Von der Lesbarkeit her sind PERFORM-Aufrufe einfach schrecklich, zumal sie bei ihren Parametern keine Formeln und keine Inline-Deklarationen erlauben und nicht funktional nutzbar sind. Allein dafür lohnt es sich schon, stattdessen Methoden zu verwenden. Die Aufteilung in DEFINITION und IMPLEMENTATION-Block halte ich für akademisch und nutzlos; das ist nur Schreibarbeit und erschwert die Lesbarkeit des Programms. Doch sogar diesen Preis bin ich für die um Längen übersichtlicheren Methodenaufrufe bereit zu zahlen. Wobei ich mir aber die Arbeit mache, die Parametrisierung meiner Methoden als Kommentar nochmal dorthin zu übertragen, wo sie meiner Meinung nach hingehört: an den Anfang der IMPLEMENTATION. Des Problems, dass solch Kommentar sich (anders als bei Funktionsbausteinen) nicht automatisch aktualisiert, wenn ich einen Parameter ändere, bin ich mir bewusst.
Die Aufteilung in Definition und Implementierung erhöht die Lesbarkeit von Klassen deutlich. Das hat also schon seinen Grund.
Wenn ich Kommentare für Parameter lese gehe ich automatisch von schlechten Parameternamen aus. 30 Zeichen reichen durchaus aus eine Bezeichnung zu wählen, die jedes Kommentar überflüssig machen. Kommentare sind per se nutzloser Wartungscode.
Da würde ich schon mal nachfragen ob derjenige überhaupt OO verstanden hat.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Wie gesagt, wenn die Zustände sinnvoll genutzt und so gut dokumentiert werden, dass auch ein anderer Entwickler nachvollziehen kann, wofür genau die Attribute stehen und wo ihre Werte herkommen (können) und wann sie gesetzt werden, dann habe ich da keine Einwände. In der von mir erlebten Praxis sehe ich aber fast nur Ein-Objekt-Klassen mit als globalen Variablen (im negativsten Sinne des Wortes) verwendeten "Attributen".
Normalerweise besteht schon ein simpler Report aus mindestens 3 Objekten. Wenn nicht hat man schon mal gegen SRP verstossen. Was sich immer rächt.
Weil eine solche Doku gar nicht notwendig ist. Woher die Werte eines Attributs kommen ist per OO Definition klar : Nur das Objekt selbst, verwaltet seine Attribute. Die Werte können also von nirgendwoher anders kommen. Ist eine Änderung nötig, dann geschieht das nach "Open-closed" Prinzip über eine Methode. Denn so behält das Objekt die Kontrolle darüber, dass seine Attribute stets konsistent geändert werden und immer konsistent sind.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Das ist ein berechtigter Einwand, ebenso wie der Umstand, dass es keine lokalen Funktionsgruppen gibt. Aber ich bitte, sich zu erinnern, was ich eigentlich sagen wollte. Ich habe nie postuliert, dass man anstelle von Klassen besser Funktionsgruppen verwenden solle, sondern wollte nur auf die auffallenden Parallelen zwischen Funktionsgruppen und abstrakten Klassen aufmerksam machen. Das wirft ein Schlaglicht auf das Konzept der "Attribute". Für mich sind "Attribute" nichts anderes als schöngeredete globale Variablen. Die Nachteile sind nämlich genau dieselben: Sie sind nicht Bestandteil des Parameterinterfaces der Methoden, und wenn man das Programm nicht selber geschrieben hat, ist es sauschwer nachzuvollziehen, wo ihre Werte herkommen und wofür sie irgendwann später im Code noch alles verwendet werden (welche Auswirkungen eine Änderung also hat). Theoretisch müsste man das superakkurat dokumentieren. Praktisch habe ich in meinem ganzen Leben noch nicht ein OO-Programm gesehen, dessen Ersteller das gemacht hätte, erst recht nicht dort, wo man solch Doku unter allen Umständen wiederfindet, nämlich direkt in der Klassen- oder Methodendokumentation.
Klassencoding ist in der Regel auch recht überschaubar. Ist er es nicht, ist fraglich ob die Architektur stimmt.
"Code lügt nicht ^^"
Also das Performanceargument trifft schon mal gar nicht zu. Warum gibt es Instanziierung ? Weil ein Objekt zu seiner Laufzeit von einem Objekt gleichen Typs ersetzt werden kann. Das kann ein FM nicht. Die auch ganz furchtbar sind.DeathAndPain hat geschrieben: ↑05.09.2024 10:41
Wie von black_adept schon eingewendet habe ich explizit "abstrakte Klassen" gesagt, also Klassen, die nicht instanziierbar sind. Bei solchen Klassen hast Du nicht mehrere Objekte für mehrere Belege (oder was auch immer). Natürlich kann man mit Instanziierung von Objekten Sachen machen, die über Funktionsgruppen hinausgehen. Das habe ich nie bestritten. Allerdings habe ich auf den Umstand hingewiesen, dass der Löwenanteil der Klassen, die ich von anderen Entwicklern zu sehen bekomme, nur genau einmal instanziiert wird. Dann aber ist die Instanziierung nutzlos und legt nur eine überflüssige Abstraktionsebene drüber, die die Performance senkt und das Programm schlechter lesbar macht.
Forms haben zusätzlich den Nachteil, das ein USING gleichzeitig ein CHANGING ist und es keine Returnparameter gibt.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Das stimmt nicht so ganz. Von der Lesbarkeit her sind PERFORM-Aufrufe einfach schrecklich, zumal sie bei ihren Parametern keine Formeln und keine Inline-Deklarationen erlauben und nicht funktional nutzbar sind. Allein dafür lohnt es sich schon, stattdessen Methoden zu verwenden. Die Aufteilung in DEFINITION und IMPLEMENTATION-Block halte ich für akademisch und nutzlos; das ist nur Schreibarbeit und erschwert die Lesbarkeit des Programms. Doch sogar diesen Preis bin ich für die um Längen übersichtlicheren Methodenaufrufe bereit zu zahlen. Wobei ich mir aber die Arbeit mache, die Parametrisierung meiner Methoden als Kommentar nochmal dorthin zu übertragen, wo sie meiner Meinung nach hingehört: an den Anfang der IMPLEMENTATION. Des Problems, dass solch Kommentar sich (anders als bei Funktionsbausteinen) nicht automatisch aktualisiert, wenn ich einen Parameter ändere, bin ich mir bewusst.
Die Aufteilung in Definition und Implementierung erhöht die Lesbarkeit von Klassen deutlich. Das hat also schon seinen Grund.
Wenn ich Kommentare für Parameter lese gehe ich automatisch von schlechten Parameternamen aus. 30 Zeichen reichen durchaus aus eine Bezeichnung zu wählen, die jedes Kommentar überflüssig machen. Kommentare sind per se nutzloser Wartungscode.
Da würde ich schon mal nachfragen ob derjenige überhaupt OO verstanden hat.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Wie gesagt, wenn die Zustände sinnvoll genutzt und so gut dokumentiert werden, dass auch ein anderer Entwickler nachvollziehen kann, wofür genau die Attribute stehen und wo ihre Werte herkommen (können) und wann sie gesetzt werden, dann habe ich da keine Einwände. In der von mir erlebten Praxis sehe ich aber fast nur Ein-Objekt-Klassen mit als globalen Variablen (im negativsten Sinne des Wortes) verwendeten "Attributen".
Normalerweise besteht schon ein simpler Report aus mindestens 3 Objekten. Wenn nicht hat man schon mal gegen SRP verstossen. Was sich immer rächt.
Weil eine solche Doku gar nicht notwendig ist. Woher die Werte eines Attributs kommen ist per OO Definition klar : Nur das Objekt selbst, verwaltet seine Attribute. Die Werte können also von nirgendwoher anders kommen. Ist eine Änderung nötig, dann geschieht das nach "Open-closed" Prinzip über eine Methode. Denn so behält das Objekt die Kontrolle darüber, dass seine Attribute stets konsistent geändert werden und immer konsistent sind.DeathAndPain hat geschrieben: ↑05.09.2024 10:41Das ist ein berechtigter Einwand, ebenso wie der Umstand, dass es keine lokalen Funktionsgruppen gibt. Aber ich bitte, sich zu erinnern, was ich eigentlich sagen wollte. Ich habe nie postuliert, dass man anstelle von Klassen besser Funktionsgruppen verwenden solle, sondern wollte nur auf die auffallenden Parallelen zwischen Funktionsgruppen und abstrakten Klassen aufmerksam machen. Das wirft ein Schlaglicht auf das Konzept der "Attribute". Für mich sind "Attribute" nichts anderes als schöngeredete globale Variablen. Die Nachteile sind nämlich genau dieselben: Sie sind nicht Bestandteil des Parameterinterfaces der Methoden, und wenn man das Programm nicht selber geschrieben hat, ist es sauschwer nachzuvollziehen, wo ihre Werte herkommen und wofür sie irgendwann später im Code noch alles verwendet werden (welche Auswirkungen eine Änderung also hat). Theoretisch müsste man das superakkurat dokumentieren. Praktisch habe ich in meinem ganzen Leben noch nicht ein OO-Programm gesehen, dessen Ersteller das gemacht hätte, erst recht nicht dort, wo man solch Doku unter allen Umständen wiederfindet, nämlich direkt in der Klassen- oder Methodendokumentation.
Klassencoding ist in der Regel auch recht überschaubar. Ist er es nicht, ist fraglich ob die Architektur stimmt.
"Code lügt nicht ^^"
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Das stimmt so nicht. Es gibt diverse andere Gründe FM zu schreiben
- RFC-FuBa
- Verbucher
- Parallelisieriung
? Ereigniskopplung?
...
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Aber wir werden uns schnell einig, wenn wir sagen: Man braucht schon einen triftigen Grund für eine Funktionsgruppe / einen Funktionsbaustein. Nicht, weil man eine Funktion braucht die man aufrufen kann, dafür sollte man wirklich besser in OO-Objekten arbeiten.black_adept hat geschrieben: ↑09.10.2024 14:36Das stimmt so nicht. Es gibt diverse andere Gründe FM zu schreiben
- RFC-FuBa
- Verbucher
- Parallelisieriung
? Ereigniskopplung?
...
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 2):
black_adept • gtoXX
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Für die Parallelisierung brauche ich keine FM mehr. Das gibt's ebenso OO basiert. Eine Verbuchungslogik per FM ist ebenfalls nur in seltenen Fällen nötig, ich kann die Konsistenz einer LUW auch anders sicherstellen. RFC Fubas brauche ich nur da, wo ich keinen Service habe. Ich weiß nicht genau, welche Ereigniskopplung du meinst, aber die SWEC z.b. kann mit Klassen umgehen. Selbst wenn ich einen FuBa noch schreibe, sollte er letztlich nichts anderes sein, als ein Wrapper für einen Objektaufruf.black_adept hat geschrieben: ↑09.10.2024 14:36Das stimmt so nicht. Es gibt diverse andere Gründe FM zu schreiben
- RFC-FuBa
- Verbucher
- Parallelisieriung
? Ereigniskopplung?
...
"Code lügt nicht ^^"
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Diese Aussage halte ich für absurd. Das TOP-Include ist nur dazu da, Typen und Felder zu definieren. Die sind funktionsgruppenglobal. Damit entspricht es der Definition von Typen und Feldern im DEFINITION-Block der Klasse, die damit dann klassenglobal sind.Funktionsgruppen sind wenn schon eher Klassen mit Vererbung. Schon aufgrund des globalen Sichtbarkeitsbereiches im TOP Include.
Vererbung ist die Möglichkeit, Klassen unter neuem Namen wiederzuverwenden und dabei bestimmte Methoden zu redefinieren (was in aller Regel auf Spezialisierung hinausläuft). Dafür ist das TOP-Include einer Funktionsgruppe komplett ungeeignet.
Eine Behauptung, die Du nicht belegst, während das Gegenteil offensichtlich ist: Jeder Befehl, also auch das Erzeugen einer Instanz, kostet Rechenzeit. Das ist mehr Rechenzeit, als stattdessen nichts zu machen, soviel steht fest. Und "stattdessen nichts machen" ist genau das, was bei einer statischen Klasse nötig ist. In dem Fall, in dem nur eine einzige Instanz erforderlich ist (und nur von diesem Fall habe ich gesprochen) ist beides funktional gleichwertig, denn eine statische Klasse hat eine implizite Instanz, die nicht händisch erzeugt werden muss. Zugleich ist die Lesbarkeit besser, da der dann nutzlose Objekterzeugungswasserkopf im Quellcode fehlt.Also das Performanceargument trifft schon mal gar nicht zu.
Als kleines Bonbon erlauben statische Methoden die Nutzung des STATICS-Befehls, was zuweilen nützlich sein kann. Kann man mit Objekten natürlich nachbauen, aber nicht so einfach.
In dem Moment, in dem Du mehrere Objektinstanzen benötigst, ja. Ich habe explizit von dem Fall gesprochen, in dem im ganzen Programm stets nur eine einzige Instanz der Klasse angelegt wird. In den "objektorientierten" Programmen, die ich von anderen zu sehen bekomme, kommt dies nicht nur vor, sondern ist sogar der erdrückende Löwenanteil. Und das finde ich bescheuert; dann brauche ich keine Instanziierung.Warum gibt es Instanziierung ? Weil ein Objekt zu seiner Laufzeit von einem Objekt gleichen Typs ersetzt werden kann.
Dafür ist bei Methoden ein EXPORTING gleichzeitig ein CHANGING, jedenfalls solange nicht explizit Wertübergabe definiert ist.Forms haben zusätzlich den Nachteil, das ein USING gleichzeitig ein CHANGING ist
Aber das nur am Rande. Wir sind uns einig, dass es sich mit Methoden bedeutend schöner arbeitet als mit Formroutinen.
Da bin ich vom Gegenteil überzeugt, aus Gründen, die ich im Verlauf dieses Threads bereits dargelegt habe. Was Du mutmaßlich nicht gelesen hast.Die Aufteilung in Definition und Implementierung erhöht die Lesbarkeit von Klassen deutlich.
Um Himmels willen, was für eine Aussage!!! Das kann ich nicht glauben, dass jemand ernsthaft sowas behauptet.Wenn ich Kommentare für Parameter lese gehe ich automatisch von schlechten Parameternamen aus. 30 Zeichen reichen durchaus aus eine Bezeichnung zu wählen, die jedes Kommentar überflüssig machen. Kommentare sind per se nutzloser Wartungscode.
Das haben diese Leute nicht, aber das wirft ein Schlaglicht auf den Umstand, das nahe an 0% der ABAP-Programmierer OO verstanden haben. Und das wiederum wirft ein Schlaglicht auf OO, denn eine Sprache, die so akademisch ist, dass keiner ihrer praktischen Verwender in der realen Welt sie wirklich versteht und weiß, wie er damit umgehen muss, ist eben genau das: akademisch und nicht praxistauglich. Auch wenn das verbleibende Prozent der Entwickler, die es verinnerlicht haben, tolle Sachen damit veranstalten kann.Da würde ich schon mal nachfragen ob derjenige überhaupt OO verstanden hat.DeathAndPain hat geschrieben:Wie gesagt, wenn die Zustände sinnvoll genutzt und so gut dokumentiert werden, dass auch ein anderer Entwickler nachvollziehen kann, wofür genau die Attribute stehen und wo ihre Werte herkommen (können) und wann sie gesetzt werden, dann habe ich da keine Einwände. In der von mir erlebten Praxis sehe ich aber fast nur Ein-Objekt-Klassen mit als globalen Variablen (im negativsten Sinne des Wortes) verwendeten "Attributen".
Nach meiner Überzeugung kann es dabei auch eine Rolle spielen, dass das Bildungsniveau in Deutschland aus Gründen, die man leider nicht mehr laut diskutieren darf, förmlich in sich zusammengebrochen ist. Das sehe ich sehr schön, wenn ich mir anschaue, was meine Kinder im Gymnasium lernen und was ich damals gelernt habe. Damals war Mathematik im Gymnasium nahezu 100% Beweise führen, gemäß dem Prinzip, dass man an der Realschule lernt, Kochrezepte korrekt anzuwenden und am Gymnasium, eigenständig zu denken und Lösungswege zu erarbeiten (statt sie nur anzuwenden). Die heutigen Mathematiklehrpläne sehen am Gymnasium keine Beweise mehr vor. Offenbar sieht man sich nicht mehr in der Lage, die Schüler zu befähigen, eigenständig eine mathematische Aussage zu beweisen. Wie sollen solche Absolventen dann eigenständig Konzepte wie OO kreativ anwenden können? Es ist einfach nur traurig. Deutschland hat keine Bodenschätze. Das Bildungsniveau ist das Einzige, was uns je ausgezeichnet hat. Ich sehe keinen Grund, weshalb Deutschland perspektivisch noch in der Lage sein sollte, seine besondere wirtschaftliche Stärke aufrechtzuerhalten. Aber ich schweife ab.
Und das Objekt kann 100 Methoden haben, die dies tun. Mit der gleichen Berechtigung könnte ich als herkömmlicher Programmierer sagen: Mein Programm selbst verwaltet seine globalen Variablen. In irgendeiner meiner Formroutinen haben sie ihre Werte erhalten (von denen Du jetzt an einer bestimmten Programmstelle grübelst, wo sie herkommen und was sie an anderer Stelle im weiteren Programmverlauf bewirken werden).Woher die Werte eines Attributs kommen ist per OO Definition klar : Nur das Objekt selbst, verwaltet seine Attribute.
Nur sind die Attribute auch dann nur dann konsistent, wenn es keine Programmierfehler gibt. Dies zu beurteilen, wenn die Klasse nicht von einem selber ist, ist alles andere als trivial. Und selbst dann kann solch fremder Code unfassbar schwer zu verstehen sein. Das ist genau die gleiche Sch… wie seinerzeit mit den herkömmlichen globalen Variablen. Genau deshalb hat man seinerzeit zu recht gesagt, die Werte, die ein ein Unterprogramm nutzt oder verändert, gehören in seine Schnittstelle. Auch wenn dieses Unterprogramm im privaten Teil der Klasse sitzt.Ist eine Änderung nötig, dann geschieht das nach "Open-closed" Prinzip über eine Methode. Denn so behält das Objekt die Kontrolle darüber, dass seine Attribute stets konsistent geändert werden und immer konsistent sind.
Du gehst von einem Objekt als einer Black Box aus, deren Inhalt und Funktionsweise von außen keinen was angeht. Das funktioniert aber nur unter zwei Prämissen: erstens musst Du genau wissen, wie man das Objekt benutzt und zweitens darfst Du Dich nie in der Verlegenheit befinden, am Code des Objektes (der Klasse) etwas ändern zu müssen. Spätestens dann musst Du die Datenflüsse innerhalb der Klasse nämlich überblicken, und das ist bei Attributen, die in Wahrheit einfach nur klassenglobale Variablen sind, ein Albtraum.
Da sind wir uns tatsächlich einmal einig.Ralf hat geschrieben:Aber wir werden uns schnell einig, wenn wir sagen: Man braucht schon einen triftigen Grund für eine Funktionsgruppe / einen Funktionsbaustein. Nicht, weil man eine Funktion braucht die man aufrufen kann, dafür sollte man wirklich besser in OO-Objekten arbeiten.
- Funktionsbausteine im BDTblack_adept hat geschrieben: ↑09.10.2024 14:36Das stimmt so nicht. Es gibt diverse andere Gründe FM zu schreiben
- RFC-FuBa
- Verbucher
- Parallelisieriung
? Ereigniskopplung?
...
- Funktionsbausteine in FQEvent-Zeitpunkten
--
Und wenn der Umfang der Entwicklungen dafür überschaubar ist, lagere ich den Code nicht zusätzlich in Klassen aus und rufe ihn dann aus dem Fuba auf. Dann bleibe ich in der Funktionsgruppe. Auch in Funktionsgruppen kann man ja Unit-Test für FORM-Routinen machen...
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das ist richtig, „überschaubar“ ist hierbei allerdings ein dehnbarer Begriff. Aus der Praxis noch ein Fall: Ein Framework für Produktionsdatenänderungen, die das Coding des FB mit ins Log schreibt (ziemlich genial gemacht), weshalb es nichts bringt, dort eine Klasse aufzurufen, weil DAS Coding freilich nicht im Log landet.
Darum DARF man dort nur im Funktionsbaustein programmieren.
Aber bei allen Fällem gilt: Man braucht einen konkreten Grund für einen FB.
Ralf
Darum DARF man dort nur im Funktionsbaustein programmieren.
Aber bei allen Fällem gilt: Man braucht einen konkreten Grund für einen FB.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Don't feed the trollsDeathAndPain hat geschrieben: ↑10.10.2024 01:24Um Himmels willen, was für eine Aussage!!! Das kann ich nicht glauben, dass jemand ernsthaft sowas behauptet.Wenn ich Kommentare für Parameter lese gehe ich automatisch von schlechten Parameternamen aus. 30 Zeichen reichen durchaus aus eine Bezeichnung zu wählen, die jedes Kommentar überflüssig machen. Kommentare sind per se nutzloser Wartungscode.
Wenn mir ein Entwickler einen simplen(!) Report mit 3 Objekten übergibt würde ich ihn fragen ob er KISS kennt. Und ehrlich gesagt verstehe ich sowieso nicht warum hier alles OO programmiert werden soll. OO hat ein paar Vorteile in bestimmten Situationen. Aber die sehe ich in den vielen ( in meinem Kundenkreis typischen ) ABAP-Programmen nicht. Und das Verwenden von Methoden statt FORMs ist halt kein OO! Methoden sind ja wie FORMs und FB nichts anderes als Modularisierungseinheiten, für welche SAP einfach das m.E. beste Interface dieser Modularisierungseinheiten anbietet.
Das glaube ich nicht. Ich denke mal, dass sehr, sehr viele ABAP Entwickler OO in Grundzügen oder sogar phantastisch beherrschen. Ich definiere einen guten/erfahrenen Entwickler so, dass er weiß in welcher Situation er welches Werkzeug verwenden sollte. Weder jemand der OO als Ultima Ratio ansieht noch jemand der dieses Thema als Teufelswerk ablehnt sind mir geheuer.DeathAndPain hat geschrieben: ↑10.10.2024 01:24Das haben diese Leute nicht, aber das wirft ein Schlaglicht auf den Umstand, das nahe an 0% der ABAP-Programmierer OO verstanden haben. Und das wiederum wirft ein Schlaglicht auf OO, denn eine Sprache, die so akademisch ist, dass keiner ihrer praktischen Verwender in der realen Welt sie wirklich versteht und weiß, wie er damit umgehen muss, ist eben genau das: akademisch und nicht praxistauglich. Auch wenn das verbleibende Prozent der Entwickler, die es verinnerlicht haben, tolle Sachen damit veranstalten kann.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
Murdock • ST22 • gtoXX
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Weil man nicht mehrere Paradigmen verwendet, sondern sich für eines (bei einem Kunden / in einem System / für sich) entscheidet.black_adept hat geschrieben: ↑10.10.2024 12:01Wenn mir ein Entwickler einen simplen(!) Report mit 3 Objekten übergibt würde ich ihn fragen ob er KISS kennt. Und ehrlich gesagt verstehe ich sowieso nicht warum hier alles OO programmiert werden soll.
Ich habe auch schon entschieden, bei einem Kunden die Abstraktion in Grenzen zu halten, weil die das sonst nicht gewartet kriegen.
Und ja: Methoden und Klassen zu verwenden ist das, was in den meisten Lebensläufen mit "ich kann OO" gemeint ist. Das ist aber eben NICHT OO und das wissen auch viele Entwicklungsleiter oder interne Entwickler nicht, die beurteilen sollen, was der Mensch taugt.
Das Problem im SAP-Bereich ist, dass viele SAP-Entwickler keine "gelernten" Softwareentwickler sind, sondern umgeschulte Maurer und Bäcker. Die haben in ihrer Umschulung gelernt, Anweisungen hintereinander zu schreiben. Mit Architektur und Abstraktion haben sie sich nie beschäftigt und das wollen sie auch nach x Jahren Arbeit in diesem Beruf nicht.
Das ist der Unterschied zum "gelernten" Softwareentwickler, der Abstraktionen versteht, der weiß was ein Interface ist und wofür man es verwendet, etc. Der muss nicht umlernen, der ist froh, dass er die neuen Techniken endlich auch im SAP hat.
Ich bin ENTSETZT, wenn ein freiberuflicher Entwickler mit 30 Jahren Erfahrung mir erzählt, dass er nicht nur noch nie einen Unit-Test geschrieben hat, sondern dass er gar nicht genau wisse, was genau das ist. Für mich ist das so wie ein Kfz-Mechatroniker, der nicht weiß, was ein Vergaser ist.
Ja, OO ist akademisch und für "einfache" Leute, die nicht Softwareentwicklung gelernt haben, schwierig. Das führt dazu, dass nur Fachleute ("richtige" Softwareentwickler) diese Arbeiten durchführen können und eben nicht Leute, die nur gelernt haben, Anweisungen hintereinander zu schreiben.DeathAndPain hat geschrieben: ↑10.10.2024 01:24Und das wiederum wirft ein Schlaglicht auf OO, denn eine Sprache, die so akademisch ist, dass keiner ihrer praktischen Verwender in der realen Welt sie wirklich versteht
Das ist übrigens bei Autos, Heizungen, Waschmaschinen und Kernkraftwerken auch so. Klar, man KANN als Nicht-Profi versuchen, Wartung und Reparaturen selbst zu machen, ist nur oft ne doofe Idee, viele reparieren dabei mehr kaputt als heile.
Bei jungen Entwicklern ist das so, bei älteren (also eher meine Generation, die umgeschulten Bäcker und Maurer) ist das Wissen um OO erschreckend niedrig. Das liegt AUCH daran, wie es ihnen erklärt wurde (egal wo man liest, man liest immer das Beispiel mit Autos und Motorrädern; ich hätte mir da etwas SAP-relevanteres gewünscht, dann versteht man das nämlich sehr schnell).black_adept hat geschrieben: ↑10.10.2024 12:01Das glaube ich nicht. Ich denke mal, dass sehr, sehr viele ABAP Entwickler OO in Grundzügen oder sogar phantastisch beherrschen.
Ralf
Disclaimer (ohne geht es ja heutzutage nicht): Das ist nicht despektierlich gegenüber Maurern und Bäckern gemeint, beide haben in meinen Augen tolle Berufe. Aber ich würde z. B. nie auf die Idee kommen, meine Wohnung selbst zu streichen, weil das NIE so gut wird wie wenn ein gelernter Maler das tut. Und ich habe auch gelernt, dass es bei allen Fortschritten in der Handy-Fotografie keine vernünftige Alternative zum professionellen Fotografen gibt, wenn es wirklich auf die Qualität ankommt.
Und genau darum erkennt man auch Qualitätsunterschiede im Arbeitsergebnis von "richtigen" Softwareentwicklern und angelernten Leuten.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Genau deshalb setze ich gerne auf statische Klassen. Nicht wirklich OO, völlig richtig, aber die deutlichen Interface-Vorteile gegenüber Formroutinen voll mitgenommen.black_adept hat geschrieben:Und das Verwenden von Methoden statt FORMs ist halt kein OO! Methoden sind ja wie FORMs und FB nichts anderes als Modularisierungseinheiten, für welche SAP einfach das m.E. beste Interface dieser Modularisierungseinheiten anbietet.
Ehrlich gemeinte Frage: Denkst Du das nur, oder kennst Du reichlich davon? Ich urteile anhand der Codes, die ich zu sehen bekomme. Solides OO mit mehr als einer Instanz pro Klasse und dann womöglich sogar noch nachvollziehbar programmiert statt leere Methodenschnittstellen und alles in globale Variablen mit Etikett "Attribut" dran - das bekomme ich so gut wie gar nicht zu sehen.black_adept hat geschrieben:Das glaube ich nicht. Ich denke mal, dass sehr, sehr viele ABAP Entwickler OO in Grundzügen oder sogar phantastisch beherrschen.
Vielleicht ist das eine Frage technischer Begabung und auch einer gewissen professionellen Einstellung. Im Laufe meines Lebens habe ich nämlich die Erfahrung gemacht, dass letztere themenübergreifend ist und auf nahezu jeden Bereich des Lebens - durchaus auch im privaten Bereich - angewendet werden kann. Wenn man etwas macht, muss man mit der Einstellung rangehen, es der Reihe nach und ordentlich zu machen und dafür die eine oder andere Extraminute einzuplanen.Ralf hat geschrieben:Das ist übrigens bei Autos, Heizungen, Waschmaschinen und Kernkraftwerken auch so. Klar, man KANN als Nicht-Profi versuchen, Wartung und Reparaturen selbst zu machen, ist nur oft ne doofe Idee, viele reparieren dabei mehr kaputt als heile.
Als junger Mensch habe ich mal mit wenig Vorkenntnissen auf gut Glück und des finanziellen Risikos bewusst meinen ersten PC selbst gebastelt (einen 386er). Das habe ich dann über die Jahre immer wieder gemacht und immer mehr Erfahrung gewonnen. Ich habe da nie eine Schulung oder dergleichen absolviert und behaupte, dass ich mittlerweile im Bauen und Reparieren von PCs (einschließlich Software) besser bin als die meisten Verkäufer in PC-Läden. Dazu wäre es nie gekommen, wenn ich mich nicht getraut hätte damit anzufangen.
Bei meinem Auto habe ich mir vor ca. 20 Jahren einfach mal gesagt, warum den Ölwechsel nicht mal selber versuchen. Ein Selbsthilfebuch gekauft, ein bisschen im Forum gelesen (motor-talk.de), für eine Stunde eine Hebebühne in einer Selbsthilfewerkstatt gemietet und los ging's. Hat auf Anhieb geklappt und nicht nur Geld gespart (keine Werkstatt-Stundenkosten und vor allem qualitativ beste Ersatzteile selbst ausgesucht und zu Internetpreisen gekauft. An denen verdienen die Werkstätten ja auch noch mal richtig!), sondern vor allem habe ich auch mein Auto besser kennengelernt. Im weiteren Verlauf habe ich dann auch angefangen, Kraftstofffilter, Motorluftfilter und Pollenfilter (Innenraumluftfilter) selber zu wechseln. Die Chance, einmal im Jahr unter dem Auto zu stehen, nutze ich seit Jahren auch, um das Auspuffrohr mit Auspuffspray und den Rest des Unterbodens mit Henkel Teroson-Wachsspray einzusprühen. Mit der Folge, dass mir seitdem noch nie das Auspuffrohr durchgerostet und gebrochen ist, was davor alle paar Jahre Standard war.
All das ohne jede Mechanikerschulung und Vorkenntnisse. Aber: ich habe mir vernünftiges Werkzeug hingelegt. Mit schlecht passendem oder minderwertigem Werkzeug aus der heimischen Grabbelkiste zu arbeiten, macht nicht nur keinen Spaß, sondern ist auch unprofessionell und führt zu schlechten Ergebnissen. Gutes Werkzeug lässt sich häufig auch für andere Sachen wiederverwenden. Und selbst wenn nicht: Letztes Jahr habe ich meine Glühkerzen neu gemacht. Da musste ich mir spezielles Werkzeug für besorgen, u.a. einen Drehmomentschlüssel, der im Bereich um 20 nm funktioniert und zudem auch linksherum (das können die wenigsten). Aber ich habe gerechnet: Eine Werkstatt mit dem Glühkerzenwechsel zu beauftragen, wäre in etwa so teuer gewesen wie das Werkzeug. So habe ich die neuen Glühkerzen und das Werkzeug - wer weiß, wann ich das nochmal gebrauchen kann. Zudem ist es bei Glühkerzen so, dass die gerne mal festgegammelt sind. Man kann vorher ein spezielles Kriechöl draufsprühen, dann man optimalerweise dann 1-2 Wochen lang einwirken lässt, während man mit dem Auto in der Gegend rumfährt. Diese Mühe macht sich keine Werkstatt. Und wenn denen dann die Glühkerze beim Herausdrehen abbricht, dann gilt das nicht als Werkstattfehler, sondern als Defekt am Wagen, der dann für die Werkstatt eine lukrative Folgereparatur mit sich bringt (da muss dann nämlich der Motor geöffnet werden, um das wieder in Ordnung zu bringen). Ich habe es selber gemacht, sorgsam auf die Drehmomente geachtet, damit eben nichts abbricht und mir alle Zeit der Welt für das Einwirkenlassen des Kriechöls gelassen. Hat prima geklappt.
Auch im medizinischen Bereich könnte ich ein Beispiel erläutern, bei dem 3 Hautärzte nacheinander übelst versagt haben und ich als Laie mir dann sehr erfolgreich selber geholfen habe - mit Mitteln aus dem Baumarkt! Insofern ist es nicht unbedingt so, dass man von Sachen, von denen man nichts versteht, unbedingt die Finger lassen sollte, weil es andernfalls Pfusch werden muss. Man muss sich nur Zeit nehmen, gut belesen und mit einer strukturierten und qualitätsorientierten (professionellen) Einstellung an die Sache herangehen.
Natürlich muss man sich dabei auch überlegen, was man sich vornimmt. An die Bremsen meines Autos gehe ich nicht selber ran. Das ist ein sicherheitsrelevanter Bereich; da gehe ich kein Risiko ein.
Das ist aber auch eine Frage der eigenen finanziellen Ausstattung. Wenn man es nicht so dicke hat, kann man sich durchaus auch mit dem Qualitätsniveau einer selbst gestrichenen Wohnung zufriedengeben, auch wenn das nicht perfekt ist. Häufig genug reicht das ja sogar für die Wohnungsabnahme beim Auszug aus einer Mietwohnung.Ralf hat geschrieben:Aber ich würde z. B. nie auf die Idee kommen, meine Wohnung selbst zu streichen, weil das NIE so gut wird wie wenn ein gelernter Maler das tut.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Immerhin gibst du zu, dass du ein Risiko eingehst. Mein Sohn hat sich zu Corona-Zeiten japanisch selbst beigebracht und hielt sich für richtig gut. Er konnte auch auf japanisch wirklich gut kommunizieren.
Jetzt studiert er Japanologie und nach seiner eigenen Aussage wusste er gar nicht, wieviel (Hintergrund)wissen er nicht hat, was ihm aber dabei hilft, WIRKLICH gut zu sein.
Das ist der Unterschied zwischen einem Bastler und einem Profi. Und wenn du dein Auto selbst reparierst, dann ist das dein Ding. Würdest du aber deine Leistung an mich verkaufen wollen, würde ich keinen Bastler haben wollen, sondern einen der es wirklich von der Pike (Pieke?) aus gelernt hat.
SAP-Entwickler verkaufen ihre Leistung an Arbeit- oder Auftraggeber und dann erwarte ich professionelles Wissen und keine angelernten Kräfte. Es gab Zeiten, da gab es diese Profis einfach nicht, da musste man darauf zurückgreifen. Ich weiß aber auch, wie viele von denen, mit denen ich meine Umschulung damals gemacht habe, noch am Markt sind.
Du musst nicht wissen, was ein Vergaser ist und was der macht, wenn du einen Ölwechsel machen willst. Wenn irgendwas schiefläuft, kannst du IMMER NOCH zum Profi gehen und es richten lassen. Vom Profi erwarte ich so breit gestreutes Wissen, dass er nicht zu wem laufen muss -- weil es über dem Profi keine Instanz mehr gibt.
Und natürlich KANN ich mich mit dem Qualitätsniveau einer selbst gestrichenen Wohnung zufriedengeben, aber das will ich nicht. Und ein Unternehmen sollte sich nicht mit dem Software-Qualitätsniveau von ehemaligen Bäckern und Maurern zufriedengeben.
Darum finde ich es nicht vermessen, von einem Softwareentwickler im Jahre 2024 (egal, wie lange der in seinem Job arbeitet) dass er mit Objektorientierung was anfangen kann. Und ja: Ich habe schon Kunden abgelehnt, weil die nach Hausregel stur prozedural programmieren. Da hat der IT-Leiter dumm aus der Wäsche geguckt, aber ich hab das durchgezogen.
Ralf
Jetzt studiert er Japanologie und nach seiner eigenen Aussage wusste er gar nicht, wieviel (Hintergrund)wissen er nicht hat, was ihm aber dabei hilft, WIRKLICH gut zu sein.
Das ist der Unterschied zwischen einem Bastler und einem Profi. Und wenn du dein Auto selbst reparierst, dann ist das dein Ding. Würdest du aber deine Leistung an mich verkaufen wollen, würde ich keinen Bastler haben wollen, sondern einen der es wirklich von der Pike (Pieke?) aus gelernt hat.
SAP-Entwickler verkaufen ihre Leistung an Arbeit- oder Auftraggeber und dann erwarte ich professionelles Wissen und keine angelernten Kräfte. Es gab Zeiten, da gab es diese Profis einfach nicht, da musste man darauf zurückgreifen. Ich weiß aber auch, wie viele von denen, mit denen ich meine Umschulung damals gemacht habe, noch am Markt sind.
Du musst nicht wissen, was ein Vergaser ist und was der macht, wenn du einen Ölwechsel machen willst. Wenn irgendwas schiefläuft, kannst du IMMER NOCH zum Profi gehen und es richten lassen. Vom Profi erwarte ich so breit gestreutes Wissen, dass er nicht zu wem laufen muss -- weil es über dem Profi keine Instanz mehr gibt.
Und natürlich KANN ich mich mit dem Qualitätsniveau einer selbst gestrichenen Wohnung zufriedengeben, aber das will ich nicht. Und ein Unternehmen sollte sich nicht mit dem Software-Qualitätsniveau von ehemaligen Bäckern und Maurern zufriedengeben.
Darum finde ich es nicht vermessen, von einem Softwareentwickler im Jahre 2024 (egal, wie lange der in seinem Job arbeitet) dass er mit Objektorientierung was anfangen kann. Und ja: Ich habe schon Kunden abgelehnt, weil die nach Hausregel stur prozedural programmieren. Da hat der IT-Leiter dumm aus der Wäsche geguckt, aber ich hab das durchgezogen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Wenn ich mit sowas neu anfange, ja. Deswegen sollte man den Rahmen am Anfang auch bescheiden stecken. Aber in dem Maße, wie ich dann Erfahrung sammele, sinkt das Risiko, und die Vorteile werden immer stärker.Immerhin gibst du zu, dass du ein Risiko eingehst.
In meinen Augen machst Du einen Fehler: Du gehst davon aus, dass jemand, der etwas von der Pike (!) auf gelernt hat, auch gut ist. Doch in allen Branchen gibt es Pfeifen, in vielen sogar reichlich. Bei Autowerkstätten ist es aber genauso. Die haben zwar alle ihre Lehre abgeschlossen, manche sogar einen Meistertitel (der freilich im wesentlichen kaufmännischer Natur ist, also da lernt man, eine eigene Werkstatt zu führen), aber was die für einen Mist machen, geht auf keine Kuhhaut. Ein Beispiel hatte ich mit den Glühkerzen schon gebracht. Ich könnte unzählige weitere anführen, die ich selber erlebt habe.Das ist der Unterschied zwischen einem Bastler und einem Profi. Und wenn du dein Auto selbst reparierst, dann ist das dein Ding. Würdest du aber deine Leistung an mich verkaufen wollen, würde ich keinen Bastler haben wollen, sondern einen der es wirklich von der Pike (Pieke?) aus gelernt hat.
In dem Moment, in dem ich die Erfahrung gesammelt habe, habe ich bei allen selbst gemachten Arbeiten den Vorteil, dass ich weiß, was ich gemacht habe. Das kann locker besser sein als der Durchschnitt der "professionellen" Werkstattleistungen. Von daher halte ich meine Eigenleistungen nicht nur für auf Augenhöhe, sondern sogar für tendenziell überlegen.
Wenn man dann noch in Autoforen aktiv ist, wo sich echte Profis und Brancheninsider tummeln (und solche, die Ahnung zu haben vorgeben, aber da kriegt man schnell ein Gefühl dafür, wer weiß, wovon er redet und wer nicht) und sich beliest oder selber Fragen stellt, dann kann man Wissen aufbauen, das in den Werkstätten oft gar nicht vorhanden ist. Einerseits Spezialwissen zum eigenen Fahrzeugmodell, das ein Mechaniker, der quer durch die Bank alles repariert, gar nicht hat (z.B. typische bekannte Schwachstellen des Modells, bei denen man bei entsprechenden Symptomen als erstes schauen sollte). Zum anderen gibt es Bereiche wie Ölkunde. Eigenschaften von Motorölen und wie sie sich im Detail unterscheiden, ist nicht (bzw. nur rudimentär) Bestandteil der Mechanikerausbildung. Auch nicht der Meisterausbildung, wie ich in diesen Foren erfahren habe. Soll heißen: Der durchschnittliche Automechaniker weiß über Motoröl nur, was über Mundpropaganda weitergetragen wird oder Ölfirmenvertreter ihm erzählen. Im wesentlichen schauen die Mechaniker, dass sie ein Öl reinkippen, dass die für das Modell vorgeschriebene Freigabenorm erfüllt und fertig. Das ist sachgerecht, aber auch nicht mehr. Denn viele Ölnormen sind lasch oder haben andere Schwächen, und man kann seinem Fahrzeug (nicht nur dem Motor) viel Gutes tun, wenn man ein Öl verwendet, das (neben der vorgeschriebenen Norm) auch noch deutlich bessere Normen erfüllt. Sowas ist schwer messbar, denn schlechtes Öl ist wie Rauchen: Zunächst mal passiert gar nichts, und man weiß nicht, ob und wann was passieren wird. Man spürt finanziell, was eine Reparatur kostet, aber nicht, was die Reparatur gekostet hätte, die notwendig geworden wäre, wenn man kein gutes Öl verwendet oder mit dem rechtzeitigen Ölwechsel geschludert hätte - denn diese Reparatur ist nie angefallen.
Ich persönlich verwende in meinem Auto seit vielen Jahren ein Öl, das formal gesehen überhaupt nicht von VW für meinen Golf freigegeben ist. Ich habe aber die Hintergedanken verstanden, die VW bei der Festlegung ihrer Ölnorm gehabt hat, kenne die Kriterien, die die Ölqualität ausmachen und weiß, dass das von mir verwendete Öl in allen Belangen überlegen ist. Mein Auto ist mittlerweile 22 Jahre alt und letztes Mal vor 2 Jahren als damals 20 Jahre altes Auto ohne Befund (und damit ohne fällige Reparaturen) durch den TÜV gekommen (diesmal war Diverses fällig; gibt halt Verschleiß). Also spricht einiges dafür, dass ich irgendwas richtig mache. Und das würde nicht so laufen, wenn ich den Wagen zum Ölwechsel in die Werkstatt geben würde, denn die würden das Standard-Longlifeöl nach VW-Norm reinfüllen. Ich könnte erklären, wo die Nachteile liegen, will die technischen Details hier aber nicht ausufern lassen.
Dann gibt es noch Effekte wie Servo- und Getriebeöl. Nach VW-Doktrin sind das "Lifetime-Füllungen", soll heißen, diese Öle müssen offiziell überhaupt nie gewechselt werden. Dahinter steht, dass VW die Lebenserwartung eines PKW mit 8 Jahren ansetzt, danach soll man sich ein neues Auto kaufen (woran sie aus offensichtlichen Gründen interessiert sind). Die Werkstätten verhalten sich nach den Vorgaben des Autoherstellers, also erzählt niemand dem Kunden, dass es keine Öle gibt, die ewig ihr Qualitätsniveau halten und man diese beiden Öle auch mal irgendwann neu machen sollte. Wer sich nicht selbst kümmert, erfährt das nicht und hat halt irgendwann Schäden an der Lenkung oder am Getriebe. Die werden dann auf das Fahrzeugalter geschoben, und man erfährt nie, dass sie komplett vermeidbar (und damit unnötig) gewesen wären.
Genauso die oben am Rande erwähnte Sache mit den Hautärzten. Drei "Profis" nacheinander ausprobiert, alle Totalausfälle. Dann selber rangesetzt und vollen Erfolg erzielt. Falls Interesse besteht, kann ich im Detail berichten, was da gelaufen ist.
Langer Rede kurzer Sinn: Deine Überzeugung, dass Fachleute mit entsprechendem Berufsabschluss bessere Leistungen bieten müssen als das, was man sich selber erarbeiten kann, teile ich keineswegs. Das kommt immer auf den Einzelfall an. Aber natürlich auch auf die eigenen Talente. Es wird sicherlich viele Leute geben, die zwei linke Hände haben und beim Versuch, selber an ihrem Auto was zu machen, nix reißen würden.
Ich halte es für einen Irrglauben, dass die neuen Leute besser sind. Bis vor zwei Jahren habe ich mit einen Kollegen zusammengearbeitet, der Ende 20 gewesen sein wird. Vorher hatte er als SAP-Berater bei der mindsquare AG gearbeitet. Sein "OO"-Code war auch nicht besser als das, was ich hier so geschildert habe.Ralf hat geschrieben:SAP-Entwickler verkaufen ihre Leistung an Arbeit- oder Auftraggeber und dann erwarte ich professionelles Wissen und keine angelernten Kräfte. Es gab Zeiten, da gab es diese Profis einfach nicht, da musste man darauf zurückgreifen. Ich weiß aber auch, wie viele von denen, mit denen ich meine Umschulung damals gemacht habe, noch am Markt sind.
Nach meiner Erfahrung ist es immer noch so, dass gute ABAP-Entwickler ein knappes Gut sind. Deshalb sind die Gehälter auch so hoch, und deswegen akzeptiert der Markt auch mittelmäßige und schlechte Leute - weil er halt nichts anderes bekommt. Ich frage mich wirklich, woher Du und black_adept die Überzeugung nehmen, dass die neuen (jungen) Leute gut seien. Kennt ihr so viele gute Entwickler? Mir laufen irgendwie fast keine über den Weg, auch nicht indirekt (dass ich fremden Code zu sehen bekommen würde, der was taugt).
Vergleichbare Themen
0
Antw.
Antw.
2318
Views
Views
OO-Themen die in anderen Threads OT sind
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
10
Antw.
Antw.
15394
Views
Views
Suche Videotutorials zu folgenden Themen
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
2
Antw.
Antw.
3468
Views
Views
Aktuelle Themen / Forschungstrends im SAP Bereich
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
18
Antw.
Antw.
6344
Views
Views
4
Antw.
Antw.
9906
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3695
vor einer Woche von Abap_neuling 14 / 3695
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 3129
vor einer Woche von a-dead-trousers 5 / 3129
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
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3695
vor einer Woche von Abap_neuling 14 / 3695
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 3129
vor einer Woche von a-dead-trousers 5 / 3129