Neue Themen als SAP Entwickler
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Genau. Und diese Testfälle kannst du beliebig oft wiederholen, wenn du sie als Test codierst. Nach jeder Änderung, nach jeder Korrektur.
Du kannst das gern von Hand machen, mein Kunde würde mich zerfleischen, wenn ich nach jeder Änderung stundenlang teste. Weil er die Stunden bezahlen muss.
Ralf
Du kannst das gern von Hand machen, mein Kunde würde mich zerfleischen, wenn ich nach jeder Änderung stundenlang teste. Weil er die Stunden bezahlen muss.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Deswegen behaupte ich sowas als Entwickler gar nicht erst, sondern melde, dass die Entwicklung fertig ist und getestet werden muss. Das ist dann Aufgabe des Kunden bzw. Fachbereichs, also desjenigen, der später damit arbeiten muss. Hat noch nie jemand wegen gemeckert.Ralf hat geschrieben:Ich bleibe dabei: Wenn mir ein Entwickler sagt "die Anwendung funktioniert" möchte ich von ihm wissen, worauf er diese Behauptung stützt. Hat er händisch Testreihen durchgeführt?
Als kleiner Bonus hält man sich damit sinnlose Zusatzwünsche vom Hals, wo dem Anwender irgendein minimaler Komfortgewinn durch eine Änderung einfällt, die Du aufwendig implementieren musst. Wenn er weiß, dass er den Kram hinterher testen muss, macht er bedeutend mehr die Abwägung zwischen Aufwand und Nutzen.
Wenn denen beim Test dann ein Spezialfall durchrutscht, dann ist das eben ein Bug, der später gefunden wird. Damit geht aber nicht der ganze Produktivalltag auf die Bretter, sondern ein Fall funktioniert nicht, und das muss man dann halt patchen.
Die bug-freie Software gibt es nicht (ab einer minimalen Programmkomplexität). Daran werdet ihr mit euren Unit Tests nichts ändern. Als akademisches Projekt hat man einst versucht, TeX komplett bugfrei zu bekommen. Um auch die letzten Bugs noch zu finden, hat man am Ende ein Preisgeld für jeden neu gemeldeten Bug ausgelobt, mit Erhöhung (Verdoppelung?) nach jedem Bug. Das ist schnell so teuer geworden, dass man dieses Bug-Bounty-Programm wieder einstellen und sich eingestehen musste, dass das Beseitigen aller Bugs ein Ding der Unmöglichkeit ist.
Im Prinzip genauso. Der Fachbereich überlegt sich alle relevanten Fallkonstellationen in einer Excel-Tabelle und testet die durch. Aber nur bei Neueinführung der Software. Wenn die dann live ist, muss nicht bei jeder Kleinigkeit, die im Code geändert wird, alles von vorne getestet werden.Ralf hat geschrieben:Nein, es ist bescheuert, für jeden möglichen Betrag einen Test zu machen. Aber für jeden grundsätzlich unterschiedlichen Beleg. Wir haben das Formular auch nicht für jeden Betrag getestet, sondern für jede mögliche unterschiedliche Kombination von Textbausteinen zum Beispiel.
Wie hättest du es denn gemacht?
Das hängt aber auch damit zusammen, dass die Software halt nicht so ein von Abhängigkeiten jenseits jeglicher Übersichtlichkeit durchzogenes Kartenhaus ist, wo der Schlag eines Schmetterlingsflügels einen Sturm auslösen kann. Um sowas zu vermeiden, kapselt man Funktionalitäten.
Andere Version: Anstatt blind "buch mich" zu sagen und zu hoffen, dass die Black Box alles richtig macht, ohne dass ich den Überblick darüber habe, sehe ich auf der Schnittstelle alle relevanten Daten (die Du unter dem Begriff "Zustand" subsummierst) und kann insofern beurteilen, was da passiert und warum.Ralf hat geschrieben:Und dann hast du genau das Problem wie mit Funktionsbauteinen, dass du eben nicht einen Beleg als Objekt hast, sondern irgendein Coding, das du mit Daten befüttern musst. So kannst du halt nicht in einer Schleife einfach sagen "buch mich", sondern musst in dieser Schleife ständig erstmal die vorgegebenen Werte ändern, weil du den Zustand ja nicht gespeichert hast.
Genau das ist es, was Du eben nicht tun kannst! Warum? Weil Deine Methoden sich bei denselben Importparametern mal so und mal anders verhalten, je nachdem, welche zusätzlichen Daten, die eben nicht Teil Deiner Schnittstelle sind , in den Objekten versteckt sind ("Zustand")! Das ist ja genau der große Nachteil von OO, dass man Unterroutinen eben nicht mehr anhand ihres Schnittstellenverhaltens beurteilen und testen kann.Ralf hat geschrieben:Und es sind ja keine theoretischen Tests. Jede Schnittstelle hat Importparameter und ein Ergebnis. Was ich nun mache, ist:
- Ich teste ob alle möglichen verschiedenen Kombinationen von gültigen Importparametern zum jeweils gewünschten Ergebnis führt
- Ich teste, ob ungültige Parameter nicht verarbeitet werden bzw. zum Fehler führen.
Und wie sollen Dich Unit Tests da retten? Willst Du damit den Weg beschreiten: "Ich habe zwar keine Ahnung mehr, wie dieses Objekt funktioniert und was diese Methode machen soll, aber bei den 50 Unit Tests, di eich vor einem Jahr dafür gebaut habe, kommen die richtigen Werte raus, also wird es schon richtig sein." Ist das der Weg, wie Du entwickeln möchtest?msfox hat geschrieben:"Sollte" und "dokumentiert" sind die Problem. Viele Entwickler dokumentieren nicht und andere machen auch mal Fehler. Damit hat die Methode nicht das Verhalten, was sie haben "sollte".
Code muss ausreichend dokumentiert sein (und sei es als Kommentartext direkt im Code). Ist er es nicht, kann man nur versuchen, sich mit dem Debugger zu retten. Wobei man da bei OO-Code bedeutend schlechtere Karten hat, weil man keine Ahnung hat, wo die Werte in den klassenglobalen Variablen, die man so schön "Attribute" nennt, herkommen.
Ohne den Fall zu kennen, wette ich, dass den Firmen genau dafür eine Frist eingeräumt worden ist. Sowas muss nicht von einem Tag auf den nächsten korrigiert werden, sondern bis zu einem Stichtag. Da gibt es immer eine entsprechende Frist.msfox hat geschrieben:Schön wär's. Vor einigen Jahren wurde der Steuersatz für Zinsen in der Gewerbesteuer von heute auf morgen vom Gericht als ungültig definiert, aber kein neuer Steuersatz festgelegt. 1) Die Komunen haben zunächst nicht mehr verzinst. 2) Dann wurde recht plötzlich der neue Steuersatz von der Politik festgelegt und das rückwirkend. Also musste irgendwie die Software das rückwirkend grade ziehen.
In Fällen wie diesen (wenn also die Politik sich bei der zeitlichen Machbarkeit mal wieder verschätzt) werden immer Fristen angepasst. Wenn jetzt die Kriterien noch nicht stehen, dann gebe ich Dir Brief und Siegel, dass es keine Strafen geben wird, wenn eine Firma das zum 01.01.25 noch nicht fertig implementiert hat. Ggf. wird man sowas sagen wie dass es zum 01.06.25 stehen und die vergangenen Monate entsprechend rückrechnen muss. Unrealistische Zeitvorgaben mit Strafbewehrung macht die Politik nicht, weil es schlicht nicht funktionieren würde.msfox hat geschrieben:Aktuelles Thema "digitaler Gewerbesteuerbescheid" über Elster. Bei der Gewerbesteuer sind für das XML noch nicht mal alle Kriterien fachlich sauber definiert. Soll aber ab 01.01.2025 möglich sein.
Das finde ich mutig. Ich würde da überhaupt nicht reingehen und anregen, den Strom von außerhalb des Gebäudes abzuklemmen.Ralf hat geschrieben: Ich würde auch als Elektriker (das hab ich wirklich mal gelernt) in einem einsturzgefährdeten Haus die Elektrik ändern.
Budgets sind betriebswirtschaftliche Realität, ebenso wie innerbetriebliche Durchsetzbarkeit. Du kannst es Dir offembar leisten, nur mit Kunden zu arbeiten, die alles zahlen. Von dieser kleinen Traumwolke herab beurteilst Du alle anderen.Ralf hat geschrieben:Wer DAFÜR kein Geld hat, sollte seinen Laden schließen. Der hat auch Firmenwagen ohne TÜV oder baut sich ein Firmengebäude ohne statische Berechnung.
Indem ich im Testsystem passende Testdaten anlege. Das ist ein Fall, bei dem Klonen aus dem Prod nicht der Weg ist. Ein Problem ist es deshalb aber nicht.Ralf hat geschrieben:Eines wollte ich ja noch anfügen: Es gibt Fälle, die im System gar nicht abgebildet sind.
Beispiel: Es gibt eine neue Regelung, die besagt, dass Sendungen, die Akkus enthalten, außen einen speziellen Aufkleber vorweisen müssen. Jetzt weißt du, dass du bald Akkus Geräten beilegen willst, die Akkubetrieben sind. Aber die hast du noch nicht im System, weil du die noch nicht hast. Oder weil die nicht auf Lager sind. Was weiß ich?
Wie testest du das?
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
In meinen Augen hat der Anwender anderes zu tun als als Softwaretester zu fungieren. Dass er Sachen abnimmt, das ist klar. Das ist aber etwas anderes als ein Test.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Deswegen behaupte ich sowas als Entwickler gar nicht erst, sondern melde, dass die Entwicklung fertig ist und getestet werden muss. Das ist dann Aufgabe des Kunden bzw. Fachbereichs, also desjenigen, der später damit arbeiten muss. Hat noch nie jemand wegen gemeckert.Ralf hat geschrieben:Ich bleibe dabei: Wenn mir ein Entwickler sagt "die Anwendung funktioniert" möchte ich von ihm wissen, worauf er diese Behauptung stützt. Hat er händisch Testreihen durchgeführt?
Wenn du dein Auto aus der Werkstatt holst, machst du eine Abnahmefahrt (im Idealfall mit dem Meister zusammen). Da merkst du, ob doch noch irgendwo was rappelt.
Aber du prüfst eben NICHT selbst, ob die Radmuttern mit der richtigen Nm-Zahl festgezogen sind, ob die Motorkennkurve richtig eingestellt ist, etc. (man merkt, ich verstehe nichts von Autos).
Das wird technisch getestet, nicht vom Anwender.
Das Mittel der Wahl heißt "Kostenschätzung".DeathAndPain hat geschrieben: ↑09.09.2024 16:15Als kleiner Bonus hält man sich damit sinnlose Zusatzwünsche vom Hals, wo dem Anwender irgendein minimaler Komfortgewinn durch eine Änderung einfällt, die Du aufwendig implementieren musst.
Richtig, aber man kann die Zahl der möglichen Fehler senken.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Die bug-freie Software gibt es nicht (ab einer minimalen Programmkomplexität). Daran werdet ihr mit euren Unit Tests nichts ändern.
Du weißt aber nicht, ob du bei Reparatur in Fall 175 versehentlich Fall 12 zerschießt. Genau DARUM habe ich Unit-Tests für jeden Fall, weil ich das sofort sehe. Noch ehe der Anwender das in die Hand kriegt.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Im Prinzip genauso. Der Fachbereich überlegt sich alle relevanten Fallkonstellationen in einer Excel-Tabelle und testet die durch. Aber nur bei Neueinführung der Software. Wenn die dann live ist, muss nicht bei jeder Kleinigkeit, die im Code geändert wird, alles von vorne getestet werden.
Ja, aber doch nicht Geschäftsvorfälle. Um beim Beispiel zu bleiben: Ich baue doch nicht unterschiedliche Formular für unterschiedliche Fälle von Bestellungen:DeathAndPain hat geschrieben: ↑09.09.2024 16:15Um sowas zu vermeiden, kapselt man Funktionalitäten.
* Bestellungen eines Neukunden
* Bestellungen eines Bestandskunden
* Bestellungen eines Kunden mit Wohnsitz im Ausland
Das sind alles logische Bedingungen, die dazu führen, dass ein Formular mal so und mal so aussieht. MEDRUCK ist das beste Beispiel dafür (für die jüngeren unter euch: Das ist das Muster-Formular der SAP für Angebote, Bestellungen und noch irgendwas).
Aber genau DAS soll ich als Aufrufer nicht machen müssen -- weil ich dazu den Buchungsprozess in seiner Implementierung kennen muss. Stattdessen nutzt man in OO ein Objekt mit einem Zustand, das natürlich darauf vertraut, dass die Schnittstelle zum Buchungsprozess auf einen solchen verweist, der in sich funktioniert und abgenommen ist.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Andere Version: Anstatt blind "buch mich" zu sagen und zu hoffen, dass die Black Box alles richtig macht, ohne dass ich den Überblick darüber habe, sehe ich auf der Schnittstelle alle relevanten Daten (die Du unter dem Begriff "Zustand" subsummierst) und kann insofern beurteilen, was da passiert und warum.
Nur so kann man überhaupt noch "Land sehen", weil man eben nicht mehr jede Funktionsimplementierung verstehen muss, die man benutzt.
Natürlich muss ich ein konsistent vorliegendes Objekt vor mir haben. Und im Test muss ich das Objekt in eben diesen Zustand versetzen, um es testen zu können.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Genau das ist es, was Du eben nicht tun kannst! Warum? Weil Deine Methoden sich bei denselben Importparametern mal so und mal anders verhalten, je nachdem, welche zusätzlichen Daten, die eben nicht Teil Deiner Schnittstelle sind , in den Objekten versteckt sind ("Zustand")! Das ist ja genau der große Nachteil von OO, dass man Unterroutinen eben nicht mehr anhand ihres Schnittstellenverhaltens beurteilen und testen kann.
Du hast immer noch nicht verstanden, dass ein Unit-Test TEIL DER Dokumentation ist, ne?DeathAndPain hat geschrieben: ↑09.09.2024 16:15Und wie sollen Dich Unit Tests da retten? Willst Du damit den Weg beschreiten: "Ich habe zwar keine Ahnung mehr, wie dieses Objekt funktioniert und was diese Methode machen soll, aber bei den 50 Unit Tests, di eich vor einem Jahr dafür gebaut habe, kommen die richtigen Werte raus, also wird es schon richtig sein." Ist das der Weg, wie Du entwickeln möchtest?
Weil das korrekte Verhalten einer Methode dort dokumentiert ist. Für jeden einzelnen denkbaren Fall. Und einen Fall, der keinen Unit-Test hat, darf es im produktiven Betrieb nicht geben -- im Gegenteil, es muss sogar Unit-Tests geben, die prüfen, dass der Fall auf einen Fehler läuft.
Ich kann natürlich auch Prosa schreiben und das in irgendeinem Word-Dokument hinterlegen, das in irgendeinem Verzeichnisbaum auf irgendeinem Projektserver hinterlegt ist. Und das dann im Zweifel keiner findet.
Oder ich mache es AM Entwicklungsobjekt mit einem Unit-Test.
Ich rate von Kommentartexten immer ab. Weil die so gut wie nie aktualisiert werden. Macht ja auch nix, läuft ja nicht auf einen Fehler. Das ist keine böse Absicht, man nimmt sich das vor und vergisst es dann.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Code muss ausreichend dokumentiert sein (und sei es als Kommentartext direkt im Code).
Ein nicht aktualisierter Unit-Test läuft auf Fehler. Den MUSS ich ändern.
Und genau davor schützen einen Unit-Tests, weil der Test sagt, welcher Fall aufgrund welcher falschen Bedingungen fehlerhaft ist. Da muss ich nicht stundenlang debuggen.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Ist er es nicht, kann man nur versuchen, sich mit dem Debugger zu retten.
Ich habe heute eine Liste fehlerhafter Fälle bekommen. Meine erste Frage war: Warum haben wir dafür keine Unit-Tests? Dann muss ich nämlich nicht herumdebuggen (das waren ein paar Stunden heute), um jeden einzelnen Fall nachzuvollziehen.
Hab ich bisher immer per Verwendungsnachweis gefunden.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Wobei man da bei OO-Code bedeutend schlechtere Karten hat, weil man keine Ahnung hat, wo die Werte in den klassenglobalen Variablen, die man so schön "Attribute" nennt, herkommen.
Und dann nimmst du erstmal 50 Betriebe und erstellst nach den neuen Regeln Steuerbescheide und für die anderen erstellst du andere (nach dem alten Steuersatz)?DeathAndPain hat geschrieben: ↑09.09.2024 16:15Ohne den Fall zu kennen, wette ich, dass den Firmen genau dafür eine Frist eingeräumt worden ist. Sowas muss nicht von einem Tag auf den nächsten korrigiert werden, sondern bis zu einem Stichtag. Da gibt es immer eine entsprechende Frist.
Viel Spaß vor Gericht....
Da fehlt ein "nicht", ich würde NICHT in einem einsturzgefährdeten Haus die Elektrik ändern. Darum werde ich auch in einer "einsturzgefährdeten" Anwendung nichts ändern.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Das finde ich mutig. Ich würde da überhaupt nicht reingehen und anregen, den Strom von außerhalb des Gebäudes abzuklemmen.Ralf hat geschrieben: Ich würde auch als Elektriker (das hab ich wirklich mal gelernt) in einem einsturzgefährdeten Haus die Elektrik ändern.
So war das gemeint.
Wer keine Qualität bezahlen will, bekommt auch keine Qualität. Ich liefere dokumentierte Qualität. Wer die nicht haben will, der muss sich wen anderen suchen, richtig.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Budgets sind betriebswirtschaftliche Realität, ebenso wie innerbetriebliche Durchsetzbarkeit. Du kannst es Dir offembar leisten, nur mit Kunden zu arbeiten, die alles zahlen. Von dieser kleinen Traumwolke herab beurteilst Du alle anderen.
Ich hab mal bei einer produzierenden Firma gesagt: "Wenn ihr eure (Produkt) so bauen würdet, wie eure IT ihr SAP-System, wäre der Laden längst pleite".
In einer elektrischen Anlage ist genau definiert, welches Kabel über welchen Weg wo hingelegt und angeschlossen wird. Da kann der Mensch in der Produktion nicht sagen "oh, ich brauche ein blaues Kabel, hab ich nicht mehr, dann nehme ich ein rotes, die hab ich noch". Oder "das Kabel ist zu kurz, dann leg ich es einmal diagonal durch den Schaltschrank, dann reicht das".
Oder indem du einen Test schreibst, der gar nicht darauf angewiesen ist, dass du einen Testfall anlegst. Das sichert, dass bei jedem Transport auf diese Funktionalität getestet wird (und nicht jemand versehentlich diese Funktion abklemmt, was keiner merkt, weil das keiner testet - seine Aufgabe war ja eine ganz andere).DeathAndPain hat geschrieben: ↑09.09.2024 16:15Indem ich im Testsystem passende Testdaten anlege. Das ist ein Fall, bei dem Klonen aus dem Prod nicht der Weg ist. Ein Problem ist es deshalb aber nicht.
Das Klonen von Produktivsystemen auf Testsysteme ist ohnehin rechtliche Grauzone, weil die Berechtigungen in Testsystemen ganz andere sind. Normalerweise DÜRFTEST du gar nicht in der Lage sein, selbst irgendwelche Materialien anzulegen, weil das Berechtigungskonzept dir das verbietet.
Ich weiß, wovon ich rede. Ich sitze jeden Tag einer Fachanwältin für IT-Recht gegenüber - meiner Frau 😉
Und kaum jemand pseudonymisiert ein Testsystem -- weil das unfassbar aufwendig ist (wenn die Bezüge dabei erhalten bleiben sollen). Und auch deshalb, weil es dann schwierig wird, einen Fall im Testsystem wiederzufinden, der im Produktivsystem als falsch erkannt wurde.
Das ist der Witz bei Unit-Tests: Ich muss die produktiven Daten gar nicht kennen, um Fälle durchtesten zu können.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Gerade in Anbetracht dessen was ich vorher geschrieben hatte, hast du leider die Ironie meines Postings nicht vollständig durchschaut. 😜😥ralf.wenzel hat geschrieben: ↑09.09.2024 16:14Genau. Und diese Testfälle kannst du beliebig oft wiederholen, wenn du sie als Test codierst. Nach jeder Änderung, nach jeder Korrektur.black_adept hat geschrieben: ↑09.09.2024 16:10
Antwort: Getestet und protokolliert an den Testfällen, die im Pflichtenheft dokumentiert wurden.
Du kannst das gern von Hand machen, mein Kunde würde mich zerfleischen, wenn ich nach jeder Änderung stundenlang teste. Weil er die Stunden bezahlen muss.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
So wird es sein. Ich bin im Moment etwas komisch drauf -- ich hab an zwei Zugfahr-Tagen insgesamt 5h Verspätung angesammelt auf der Strecke HH-EF und zurück. Ich verpacke das nervlich einfach nicht mehr mit RLS (und als Suchtraucher 😉) stundenlang in dieser Röhre eingesperrt zu sein, die irgendwo "auf unbestimmte Zeit" in der Walachei steht. In einem Zug, in dem es kaum noch was zu essen oder zu trinken gibt, weil man damit freilich nicht gerechnet hat.black_adept hat geschrieben: ↑09.09.2024 17:57Gerade in Anbetracht dessen was ich vorher geschrieben hatte, hast du leider die Ironie meines Postings nicht vollständig durchschaut. 😜😥
Ich hab jetzt meine BahnCard 1. Klasse gekündigt. Ich arbeite remote und fahre (weil ich das Bahnfahren vermeide) so wenig, dass sich das nicht mehr lohnt.
Zukünftig fahre ich Auto -- ist ja selten genug, dass ich noch rumfahre.
Ralf
PS: Das soll kein BahnThread werden, nur zur Erklärung
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Dieses Vorgehen ist TDD ( Test Driven Development ).DeathAndPain hat geschrieben: ↑09.09.2024 16:15Und wie sollen Dich Unit Tests da retten? Willst Du damit den Weg beschreiten: "Ich habe zwar keine Ahnung mehr, wie dieses Objekt funktioniert und was diese Methode machen soll, aber bei den 50 Unit Tests, di eich vor einem Jahr dafür gebaut habe, kommen die richtigen Werte raus, also wird es schon richtig sein." Ist das der Weg, wie Du entwickeln möchtest?
Wenn du ein Beispiel sehen willst und ein System mit ABAP2XLSX unter den Fingern hast: In der Klasse ZCL_EXCEL_COMMON sind diverse UnitTests abgebildet. Ich erinnere mich, als jemand aus Kanada die Methode SHIFT_FORMULA implementiert hatte und ich das per Hand getestet hatte (weil ich den Code einfach nicht verstanden hatte ) und dabei diverse Fehler entdeckt hatte. Ich habe mit demjenigen ein paar Mal hin- und hergemailt und dann einfach den Unit-Test den du dort findest bereitgestellt und er hat seine Methode so lange angepasst bis diese, in meinen Augen am häufigsten auftretenden Testfälle erledigt waren. Also genau so wie du es beschreibst. Einer wusste was getestet werden soll ( bzw. was am Ende rauskommen solle ) und der andere entwickelt es und wenn man an dem Codingwust mal was refactoren sollte müssen mindestens diese Testfälle weiterhin funktionieren.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ralf.wenzel • msfox
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Und noch eine lustige Anekdote dazu: Ja - ich habe es tatsächlich schon erlebt, dass genau so vorgangen wurde. Dann wurde die Entwicklung in ein weit entfernt liegendes Land ausgelagert und am Ende wurden alle Testfälle sauber durchlaufen. Da es vor 4.6 Release war gab es noch keine Klassen sondern die Testfälle waren anders dokumentiert. Und dann war es tatsächlich so, dass *Klischee bestätigt* genau diese Testfälle funktioniert hatten und bei allen anderen Testdaten zufällige Daten herauskamen. Grund: Im Code fanden sich diverse IF-Abfragen, die schlussendlich die Testfälle in einer Art heimlicher CASE-Anweisung aufteilten und dann das (hart codierte) korrekte Ergebnis zurückgegeben wurde.DeathAndPain hat geschrieben: ↑09.09.2024 16:15Und wie sollen Dich Unit Tests da retten? Willst Du damit den Weg beschreiten: "Ich habe zwar keine Ahnung mehr, wie dieses Objekt funktioniert und was diese Methode machen soll, aber bei den 50 Unit Tests, di eich vor einem Jahr dafür gebaut habe, kommen die richtigen Werte raus, also wird es schon richtig sein." Ist das der Weg, wie Du entwickeln möchtest?
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
tar
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Und das ist das Problem. Fast überhaupt keine Werkstatt schert sich um den für das Fahrzeugmodell richtigen Drehmoment. Da wird mit dem Pressluftschrauber die Schraube voll rangeknallt und fertig. Dass Du dann bei der Panne die mit 200 nm festgezogene Schraube nicht gelöst bekommst, ist denen doch egal.Aber du prüfst eben NICHT selbst, ob die Radmuttern mit der richtigen Nm-Zahl festgezogen sind, ob die Motorkennkurve richtig eingestellt ist
Selbst die, die mit Drehmomentschlüssel arbeiten, machen das nie lehrbuchmäßig aus der drehenden Bewegung heraus.
Und bei meinem letzten Zahnrippenriemenwechsel hat mein Meister mich darauf aufmerksam gemacht, dass derjenige, der das das letzte Mal gemacht hat (ist alle 6 Jahre fällig), die Motorsteuerzeiten mies eingestellt hat.
Hast also genau die beiden richtigen Beispiele getroffen. 😜
Doch, weil ich statt Kartenhaustaktik Funktionalitäten sauber kapsele.Du weißt aber nicht, ob du bei Reparatur in Fall 175 versehentlich Fall 12 zerschießt.
Das kommt darauf an. Wenn sie sich nur in der Überschrift unterscheiden, dann sicher nicht, denn dann ist der Unterschied trivial. Wenn es freilich lauter Fallunterscheidungen und Sonderlocken bedarf, beides mit einem Formular abzuhandeln, dann sehe ich durchaus Vorteile darin, zwei getrennte Formulare zu entwerfen (die als Kopien voneinander anfangen können) und so Querabhängigkeiten und ausufernde Komplexitätsgrade zu vermeiden.Ja, aber doch nicht Geschäftsvorfälle. Um beim Beispiel zu bleiben: Ich baue doch nicht unterschiedliche Formular für unterschiedliche Fälle von Bestellungen
Das stimmt nicht. Wenn ich auf der Schnittstelle (als Beispiel) Quellkontonummer, Zielkontonummer, Betrag und Referenz übergebe, dann muss ich nicht wissen, wie genau die gerufene Methode die Buchung ausführt. Aber dann weiß ich ganz genau, was sie tun soll und sage nicht nur „buch mal, ich habe zwar keine Ahnung, was Du da machst (das hat Dir zu einem früheren Zeitpunkt irgendwer schon gesagt), hoffe aber, dass es schon richtig sein wird und im Fehlerfall kann ich nicht beurteilen, was schief gegangen ist, da ich nicht weiß, was hätte passieren sollen“Ralf hat geschrieben:Aber genau DAS soll ich als Aufrufer nicht machen müssen -- weil ich dazu den Buchungsprozess in seiner Implementierung kennen muss.DeathAndPain hat geschrieben:Andere Version: Anstatt blind "buch mich" zu sagen und zu hoffen, dass die Black Box alles richtig macht, ohne dass ich den Überblick darüber habe, sehe ich auf der Schnittstelle alle relevanten Daten (die Du unter dem Begriff "Zustand" subsummierst) und kann insofern beurteilen, was da passiert und warum.
Was Du freilich nicht tun kannst, da das Objekt nicht von Dir ist und Du gar nicht weißt, was seine Zustände bedeuten und wo sie herkommen. Detaillierte Doku dazu machen 0% der Entwickler (dennoch glaube ich Dir gerne, dass Du die eine Ausnahme bist).Ralf hat geschrieben:Und im Test muss ich das Objekt in eben diesen Zustand versetzen, um es testen zu können.
Sie erleichtern – um nicht zu sagen – ermöglichen aber zu verstehen, was der folgende Codeabschnitt tut und warum. Natürlich ist auch hier die Moral mäßig, aber zumindest liegt die Zahl der Entwickler, die erklärende Kommentartexte einfügen, nicht bei 0%.Ralf hat geschrieben:Ich rate von Kommentartexten immer ab. Weil die so gut wie nie aktualisiert werden.
Nahe bei 0% liegt freilich die Zahl der Entwickler, die die von SAP automatisch generierten Mülltexte wie
Code: Alles auswählen.
*****************
* Text <--
* --> Text
*****************Mit der Begründung könntest Du auch globale Variablen klassischen Zuschnitts gutheißen, selbst in herkömmlichen prozeduralen Programmen. Per Verwendungszweck findest Du immer eine Palette von über den Code verstreuten Nutzungsstellen. Ob Du anhand dessen freilich begreifst, wie das Feld semantisch genutzt wird, möchte ich dahingestellt sein lassen.Ralf hat geschrieben:Hab ich bisher immer per Verwendungsnachweis gefunden.
Wenn die Vorgabe vom Gesetzgeber lautet „ab dem 01.01.2024 dürfen Steuerbescheide nach den neuen Regeln erstellt werden, ab dem 01.01.2025 sind die neuen Regeln dann verbindlich“ – dann ja. Wobei die Regel in solch Fall vermutlich eher lauten wird: „Heute ist der 15.02.2024. Die Bescheide für 2025 müssen in der neuen Form erstellt werden.“Ralf hat geschrieben:Und dann nimmst du erstmal 50 Betriebe und erstellst nach den neuen Regeln Steuerbescheide und für die anderen erstellst du andere (nach dem alten Steuersatz)?
Da kannst Du dann in aller Ruhe Deinen Prototyp erstellen, damit Bescheide für eine Handvoll Pionierkunden erstellen, diese Bescheide detailliert händisch prüfen (deshalb nicht gleich für so viele Kunden, dass das nicht praktikabel wäre), und wenn die Bescheide inhaltlich passen, dann rollst Du das - rechtzeitig vor 2025 - für alle Kunden aus.
Wie black_adept schon ausgeführt hat, bist Du in der luxuriösen Situation, Dir das aussuchen zu können. Gerade vor ein paar Wochen musste ich in einem Programm Korrekturen vornehmen, bei dem man erkennen konnte, dass vor mir schon mehrere andere Leute dran gewesen sind. Jeder hat an einer Stelle irgendwas gemacht und die dort sichtbare Falte des Teppichs glattgezogen, ohne zu sehen, wo dadurch an anderer Stellen neue Falten entstehen. Offenkundig wurde dabei das Gesamte nicht überblickt, so dass es für mich schwer bis kaum machbar war zu erkennen, was denn das Sollverhalten war. Aber das konnte ich mir nicht aussuchen; der Fachbereich wollte die Korrekturen haben, und es war meine Aufgabe, das zu machen. Da habe ich dann beherzt nach Gutdünken aufgeräumt, umstrukturiert und Fragen gestellt und dem Fachbereich ganz deutlich gesagt: „Ich habe dieses Chaos mit hohem Aufwand in einen Zustand gebracht, der zumindest mal wieder einigermaßen verständlich (und damit wartbar) ist, aber da das Programm geradezu widersprüchliche Codestellen enthalten hat (z.B. „Selektiere alle Zeilen aus der Datenbank, bei denen Spalte X den Wert A oder B hat“ - und danach dann eine Fallunterscheidung, in der für alle Ergebniszeilen, bei denen X den Wert C hat, ein Unterprogramm aufgerufen wird“), habe ich dem Fachbereich gesagt, dass das Programmverhalten sich durch meine Eingriffe in unvorhersagbarer Weise geändert haben kann und sie daher alles prüfen müssen, ob es (noch) so rauskommt, wie sie es haben wollen, nicht nur den Teil, den sie von mir geändert/korrigiert haben wollten.Ralf hat geschrieben:Da fehlt ein "nicht", ich würde NICHT in einem einsturzgefährdeten Haus die Elektrik ändern. Darum werde ich auch in einer "einsturzgefährdeten" Anwendung nichts ändern.
Schön ist das nicht, aber der Kunde ist König.
Wieso, das mit den kurzen Kabeln macht Airbus doch auch so. 😁Ralf hat geschrieben:In einer elektrischen Anlage ist genau definiert, welches Kabel über welchen Weg wo hingelegt und angeschlossen wird. Da kann der Mensch in der Produktion nicht sagen "oh, ich brauche ein blaues Kabel, hab ich nicht mehr, dann nehme ich ein rotes, die hab ich noch". Oder "das Kabel ist zu kurz, dann leg ich es einmal diagonal durch den Schaltschrank, dann reicht das".
Jedes Unternehmen kann doch selbst festlegen, wem es in welchen Systemen Zugriff auf seine Materialdaten gewährt; da gibt es doch keine rechtlichen Vorgaben für. Spannender wird es z.B. im HCM-Modul, wenn wir also von Personaldaten reden. Deshalb haben professionelle Cloningtools Anonymisierungsfunktionen, mit denen auf eine vorher definierte Art und Weise sensible Daten anonymisiert werden.Ralf hat geschrieben:Das Klonen von Produktivsystemen auf Testsysteme ist ohnehin rechtliche Grauzone, weil die Berechtigungen in Testsystemen ganz andere sind. Normalerweise DÜRFTEST du gar nicht in der Lage sein, selbst irgendwelche Materialien anzulegen, weil das Berechtigungskonzept dir das verbietet.
Ich habe Datenschutz an der Uni gehabt und bin Spezialist für das HCM-Modul. Da muss ich auch wissen, worauf ich zu achten habe.Ralf hat geschrieben:Ich weiß, wovon ich rede. Ich sitze jeden Tag einer Fachanwältin für IT-Recht gegenüber
Da scheint Dir die Erfahrung zu fehlen. Wenn Du z.B. Clone&Test von Accenture einsetzt, dann definierst Du dort ein sog. „Anonymisierungsset“. Darin kannst Du genau festlegen, welche Felder wie ersetzt werden sollen. Beispielsweise kannst Du sagen, ersetze jeden Vor- und Nachnamen durch einen aus einem Pool von Vor- und Nachnamen. Alle Gehälter werden auf 1000 € gesetzt (oder auf eine Zufallszahl) usw.Ralf hat geschrieben:Und kaum jemand pseudonymisiert ein Testsystem -- weil das unfassbar aufwendig ist
Dann kannst Du (oder ein weniger versierterer Kollege) einfach die Anonymisierung mit diesem Set starten, und alles wird entsprechend anonymisiert. Das ist dann überhaupt kein Aufwand mehr, wenn das Set erst einmal steht. Da muss man sich also einmal Gedanken drüber machen, was anonymisiert werden muss, dann wird das in ein Anonymisierungsset, also ein Regelwerk, gegossen, und dann hat man überhaupt keine Arbeit mehr damit.
Wenn man natürlich ohne Anonymisierung klonen möchte, um eine Probeabrechnung durchführen zu können, dann muss man natürlich auch das Testsystem auf demselben Niveau wie das Produktivsystem absichern.
Wieso erinnert mich das nur an den Dieselskandal... 😊black_adept hat geschrieben: Und dann war es tatsächlich so, dass *Klischee bestätigt* genau diese Testfälle funktioniert hatten und bei allen anderen Testdaten zufällige Daten herauskamen. Grund: Im Code fanden sich diverse IF-Abfragen, die schlussendlich die Testfälle in einer Art heimlicher CASE-Anweisung aufteilten und dann das (hart codierte) korrekte Ergebnis zurückgegeben wurde.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
OK, das Beispiel war doof, ich kenne Wartung eher aus dem Flugzeugbau und da wird sehr streng nach Vorschrift gearbeitet.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Und das ist das Problem. Fast überhaupt keine Werkstatt schert sich um den für das Fahrzeugmodell richtigen Drehmoment.
Gut, dass ich kein Auto habe....
Das kannst du ja gar nicht. Nehmen wir an, du musst eine bestimmte Bedingung in einer Methode erfüllen. Und dann kommt ein zweiter Fall hinzu, wo die Bedingung eine andere ist (die erste aber weiterhin gelten muss). Bei hinreichender Komplexität der Bedingungen ist das gar nicht so einfach, die so zu verändern, dass beide gelten.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Doch, weil ich statt Kartenhaustaktik Funktionalitäten sauber kapsele.Du weißt aber nicht, ob du bei Reparatur in Fall 175 versehentlich Fall 12 zerschießt.
Mit Kapseln meinst du wahrscheinlich, du schreibst eine Methode für Bedingung 1 und eine für Bedingung 2 -- das ist aber nicht meine Art, vorzugehen. Jede Funktionalität schreibe ich genau EINMAL.
Nein, ich hab in 25 Jahren noch keinen Kunden gehabt, der für das gleiche Formular unterschiedliche SAP-Formulare hatte. Also mehrere Bestellformulare oder so.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Das kommt darauf an.Ja, aber doch nicht Geschäftsvorfälle. Um beim Beispiel zu bleiben: Ich baue doch nicht unterschiedliche Formular für unterschiedliche Fälle von Bestellungen
Genau so macht man das in OO. Es gibt ein Objekt das irgendwas macht und der Aufrufer muss sich um das "Wie" nicht kümmern. Oder genauer: SOLL sich nicht kümmern. Man vertraut darauf, dass es funktioniert (durch Zuweisung der Verantwortlichkeit).DeathAndPain hat geschrieben:Andere Version: Anstatt blind "buch mich" zu sagen und zu hoffen, dass die Black Box alles richtig macht
Wenn ich einen Angestellten habe, der meine Buchführung macht (was ich zum Glück habe), dann kümmere ich mich nicht mehr darum. Er weiß, dass er es gut machen muss, weil ER dafür verantwortlich ist und ich ihm die ... abreiße wenn die falsch ist.
DeathAndPain hat geschrieben: ↑11.09.2024 21:15Das stimmt nicht. Wenn ich auf der Schnittstelle (als Beispiel) Quellkontonummer, Zielkontonummer, Betrag und Referenz übergebe, dann
....ist das schon viel zu viel kümmern. Woher weißt du, ob du den Namen des Kontoinhabers mitgeben musst oder ob das Objekt den selbst selektiert? Oder nur unter bestimmten Bedingungen selbst selektiert?
Du musst das Datenpaket für dein Objekt durch dein Programm transportieren bis du buchen willst. Das ist viel zu viel Kümmern.
Darum schreibt jeder Entwickler für seine Objekte die Tests selbst. Ich schreibe ja nicht den Test für ein Objekt, das jemand anderes erstellt hat.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Was Du freilich nicht tun kannst, da das Objekt nicht von Dir ist und Du gar nicht weißt, was seine Zustände bedeuten und wo sie herkommen.Ralf hat geschrieben:Und im Test muss ich das Objekt in eben diesen Zustand versetzen, um es testen zu können.
Na, WAS das Coding macht, das steht ja im Coding. Das einzige, was das Coding nicht immer erklärt, ist: WARUM macht es das? Gibt es einen Zusammenhang, der nicht offensichtlich ist? DEN kann man gern kommentieren. Aber damit fallen 95% aller mit bekannten Kommentare weg in denen z. B. vor eine Loop steht "Einkaufsbelege abarbeiten".DeathAndPain hat geschrieben: ↑11.09.2024 21:15Sie erleichtern – um nicht zu sagen – ermöglichen aber zu verstehen, was der folgende Codeabschnitt tutRalf hat geschrieben:Ich rate von Kommentartexten immer ab. Weil die so gut wie nie aktualisiert werden.
Nein, weil die keinen Sinn haben außer "ist einfacher". Im Gegensatz zu einer normalen Variablen ist aber ein Attribut dafür da, ein Objekt in einen definierten ZUSTAND zu versetzen. Wenn man natürlich zustandslos programmiert wie du, hast du recht. Aber ich kenne niemanden, der das ernsthaft tut und durchhält.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Mit der Begründung könntest Du auch globale Variablen klassischen Zuschnitts gutheißen, selbst in herkömmlichen prozeduralen Programmen.
Ich denke, wir können uns alle den Auftraggeber (AKA Arbeitgeber) aussuchen.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Wie black_adept schon ausgeführt hat, bist Du in der luxuriösen Situation, Dir das aussuchen zu können.
Ich habe durchaus schon Wartung abgelehnt mit dem Hinweis: Das einzige, was ich da mache, ist es neu zu schreiben. Aber in diesem kaputten Haus werde ich keine Lampe auswechseln (um bei dem Bild zu bleiben). Wenn die eigene Reputation das hergibt, dass das einen Wert hat, wenn man sagt "das ist nicht mehr zu warten", sollte das auf offene Ohren stoßen.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Offenkundig wurde dabei das Gesamte nicht überblickt, so dass es für mich schwer bis kaum machbar war zu erkennen, was denn das Sollverhalten war. Aber das konnte ich mir nicht aussuchen; der Fachbereich wollte die Korrekturen haben, und es war meine Aufgabe, das zu machen.
Eigentlich antworte ich darauf immer "aber nur wenn ich nicht der Sklave bin". In diesem Falle hast du recht: Der Kunde ist König, darum hat er nur das Beste verdient was man ihm geben kann und das wäre eine Neuentwicklung.
DeathAndPain hat geschrieben: ↑11.09.2024 21:15Jedes Unternehmen kann doch selbst festlegen, wem es in welchen Systemen Zugriff auf seine Materialdaten gewährt; da gibt es doch keine rechtlichen Vorgaben für.
Ich habe in 25 Jahren noch keinen Kunden gesehen, der sein Testsystem pseudonymisiert (du schreibst weiter unten von Anonymisierung, was natürlich Quatsch ist, den Unterschied darfst du gern nachschlagen - bei Anonymisierung würden ja alle Bezüge verloren gehen z. B. zwischen Bestellung und Lieferung).DeathAndPain hat geschrieben: ↑11.09.2024 21:15Spannender wird es z.B. im HCM-Modul, wenn wir also von Personaldaten reden. Deshalb haben professionelle Cloningtools Anonymisierungsfunktionen, mit denen auf eine vorher definierte Art und Weise sensible Daten anonymisiert werden.
Mit Verlaub und wirklich mit vollem Respekt dir gegenüber: Wenn jemand die Begriffe Pseudonymisierung und Anonymisierung falsch verwendet und von Kompetenz in Sachen Datenschutz spricht.... Dann vertraue ich lieber der Aussage meiner Frau 😉DeathAndPain hat geschrieben: ↑11.09.2024 21:15Ich habe Datenschutz an der Uni gehabt und bin Spezialist für das HCM-Modul. Da muss ich auch wissen, worauf ich zu achten habe.
Jaja, und jetzt hast du im Produktivsystem einen Fehler in Bestellung 12345 und eine Kopie, auf der die Bestellung auch drauf ist, du aber die Bestellung nicht kennst. Du kannst also den Fehler nicht nachvollziehen. DAS meinte ich mit Aufwand.DeathAndPain hat geschrieben: ↑11.09.2024 21:15Da scheint Dir die Erfahrung zu fehlen. Wenn Du z.B. Clone&Test von Accenture einsetzt, dann definierst Du dort ein sog. „Anonymisierungsset“.Ralf hat geschrieben:Und kaum jemand pseudonymisiert ein Testsystem -- weil das unfassbar aufwendig ist
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Dann ist es ja richtig pfiffig, dass Du jetzt Deine Bahncard kündigst und Auto fährst. 😁Gut, dass ich kein Auto habe....
Da sehe ich die Wahrheit in der Mitte. Wenn die beiden Funktionalitäten sich nur minimal unterscheiden (genanntes Beispiel: Überschrift des zu erstellenden Belegs), kann man sie in einer Methode zusammenfassen. Ansonsten schreibe ich die relevante Funktionalität auch nur einmal, und zwar dergestalt, dass ich sie in eine Untermethode auslagere, die von beiden Methoden genutzt wird. Ich habe dann also eine Methode pro Funktionalität, aber sie sind beide sehr kurz und übersichtlich, weil sie beide (für sich getestete) Untermethoden rufen, die den Teil der Funktionalität abbilden, der bei beiden gleich ist. Damit sieht man in den Obermethoden sehr schön genau den Funktionalitätsunterschied. Die Untermethoden haben eine genau definierte Funktionalität, die sich aus ihrer Schnittstelle und nicht aus in klassenglobalen Variablen, dem ABAP Memory oder sonst einem Geheimversteck hinterlegten Werten ergibt. Sie sind getestet und funktionieren. Dann kann ich Obermethoden mit angepasster Funktionalität hinzufügen, ohne das Bestehende zu gefährden, zugleich aber auch ohne bestehende und bewährte Funktionalität ein zweites Mal implementieren zu müssen!Mit Kapseln meinst du wahrscheinlich, du schreibst eine Methode für Bedingung 1 und eine für Bedingung 2 -- das ist aber nicht meine Art, vorzugehen. Jede Funktionalität schreibe ich genau EINMAL.
Ganz einfach: Wenn ich ihn mitgeben muss, kriege ich schon zur Compile-Time eine Fehlermeldung, weil ich den zugehörigen, nicht optionalen Parameter nicht versorgt habe.Woher weißt du, ob du den Namen des Kontoinhabers mitgeben musst oder ob das Objekt den selbst selektiert?
Du unterstellst, dass Coding immer selbsterklärend und leicht verständlich ist oder gemacht werden kann. Das halte ich für eine Illusion. Zum einen gibt es komplexe Zusammenhänge, die sich auch bei guter Modularisierung nicht immer perfekt überschaubar gestalten lassen, zum anderen hat man als Programmierer einen Plan im Kopf, wie man das zu lösende Problem mit einem Code abdecken möchte. Dieser Lösungsweg ist nicht immer offensichtlich. Mit genug Aufwand mag er sich bei vernünftigem Code immer reverse engineeren lassen, aber gut lesbarer Code ist auch deshalb gut lesbar, weil man beim Lesen eben nicht immer ohne Ende Aufwand reinstecken muss, um zu begreifen, was da passiert. Und da ist erklärender Kommentartext, der den vom Programmierer gewählten Lösungsansatz beschreibt, sehr hilfreich. Das fängt schon damit an, dass der Leser auf diese Weise schnell erkennt, ob der betreffende Programmabschnitt der ist, den er gerade sucht.Na, WAS das Coding macht, das steht ja im Coding.
Aus dem eben genannten Grund stimmt das nicht. Wenn ich den Code durchschaue und den Teil suche, der sich um die Verkaufsbelege dreht, dann reicht mir diese knappe Überschrift, um zu erkennen, dass ich diesen Block überspringen und woanders weitersuchen kann.Gibt es einen Zusammenhang, der nicht offensichtlich ist? DEN kann man gern kommentieren. Aber damit fallen 95% aller mit bekannten Kommentare weg in denen z. B. vor eine Loop steht "Einkaufsbelege abarbeiten".
Wie schon zuvor erläutert, habe ich das Konzept der „Zustände“ zwar verstanden, halte es aber für hochproblematisch, weil die gravierenden Nachteile globaler Variablen bei den „Zuständen“ in vollem Umfang fortbestehen. Ob Du es „Attribut“ oder „Zustand“ nennst: Einer schlechten Sache einen schönen Namen zu geben, macht sie nicht besser, da es ihre Natur nicht ändert.Im Gegensatz zu einer normalen Variablen ist aber ein Attribut dafür da, ein Objekt in einen definierten ZUSTAND zu versetzen.
Meines Wissens bist Du auch nicht im HCM-Modul unterwegs. Da ist das gängig.Ich habe in 25 Jahren noch keinen Kunden gesehen, der sein Testsystem pseudonymisiert
Ich kenne den Unterschied, habe aber nicht jedes Wort auf die Goldwaage gelegt, da das hier eine lockere Forumsdiskussion ist und kein Schreiben an ein Gericht. Und wie gesagt, selbst Accenture nennt es in ihrem Produkt „Anonymisierungsset“. Aber da es Dir so wichtig ist, will ich mir im weiteren Verlauf Mühe geben, darauf zu achten.Mit Verlaub und wirklich mit vollem Respekt dir gegenüber: Wenn jemand die Begriffe Pseudonymisierung und Anonymisierung falsch verwendet und von Kompetenz in Sachen Datenschutz spricht
Dann würde man ggf. diese eine Bestellung noch mal klonen, wenn die Bestellnummer pseudonymisiert wurde. Allerdings wird man typischerweise solche Nummern nicht pseudonymisieren, sondern nur die damit einhergehenden Daten (Kunde etc.). Da muss man dann natürlich schauen, ob der Testfall damit den Bach runtergeht. In diesem Fall klont man den Testfall einmal ohne Pseudonymisierung. Das hatte ich schon. Dann hat man eine Personalnummer als Echtdaten im Testsystem, debuggt damit eine Stunde den Fehler und löscht sie anschließend wieder raus, nachdem man gefunden hat, was man gesucht hat. Theoretisch könnte natürlich in der genau einen Stunde ein anderer Benutzer mit seinen Testsystemrechten, die über seine Prod-Rechte hinausgehen, die Personalnummer erspähen und reinschauen (obgleich er gar nicht weiß, dass es sie gibt). In der Praxis ist sowas freilich so unrealistisch, dass man es als nicht relevant einschätzen kann.Jaja, und jetzt hast du im Produktivsystem einen Fehler in Bestellung 12345 und eine Kopie, auf der die Bestellung auch drauf ist, du aber die Bestellung nicht kennst. Du kannst also den Fehler nicht nachvollziehen. DAS meinte ich mit Aufwand.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Dreimal im Jahr, öfters fahre ich nirgends mehr hin. Weil ich weder Bahnfahren noch Autofahren will.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Dann ist es ja richtig pfiffig, dass Du jetzt Deine Bahncard kündigst und Auto fährst. 😁Gut, dass ich kein Auto habe....
Bei Einzelfeldern. Ich würde erwarten, dass man solche Felder in einer Struktur übergibt (oder noch besser: in einem Objekt 😉 ).DeathAndPain hat geschrieben: ↑12.09.2024 17:36Ganz einfach: Wenn ich ihn mitgeben muss, kriege ich schon zur Compile-Time eine Fehlermeldung, weil ich den zugehörigen, nicht optionalen Parameter nicht versorgt habe.Woher weißt du, ob du den Namen des Kontoinhabers mitgeben musst oder ob das Objekt den selbst selektiert?
Wer sich nicht die Mühe macht, Coding selbsterklärend zu schreiben, schreibt auch keine erklärenden Kommentare.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Du unterstellst, dass Coding immer selbsterklärend und leicht verständlich ist oder gemacht werden kann.Na, WAS das Coding macht, das steht ja im Coding.
Und wenn doch, hat er die Prioritäten falsch gesetzt.
Darum erklärt man das "Warum", nicht das "Was"
Du meinst sowas wie "LOOP AT einkaufsbelege ASSINING...."? Das wäre selbsterklärend.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Aus dem eben genannten Grund stimmt das nicht. Wenn ich den Code durchschaue und den Teil suche, der sich um die Verkaufsbelege dreht, dann reicht mir diese knappe Überschrift, um zu erkennen, dass ich diesen Block überspringen und woanders weitersuchen kann.
Ungenauigkeiten in der Kommunikation sind eine häufige Fehlerursache. Darum wird man sowas bei mir nicht finden.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Ich kenne den Unterschied, habe aber nicht jedes Wort auf die Goldwaage gelegt, da das hier eine lockere Forumsdiskussion ist und kein Schreiben an ein Gericht.
Das ist dann das nächste Problem.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Da muss man dann natürlich schauen, ob der Testfall damit den Bach runtergeht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Das möchte ich voll unterstüzten. @Ralf: Stell dir vor du hast die Aufgabe die Ausgabe einer Funktion hinreichend zu optimieren. Du hast die grobe Wahl zwischen Intervallhalbierung, Sekantenverfahren oder Newtonverfahren ( weil du die 1. Ableitung der Funktion genähert abbilden kannst ). Ehrlich gesagt glaube ich nicht, dass > 50% der Entwickler jedes dieser Verfahren allein am Coding erkennen könnten.DeathAndPain hat geschrieben: ↑12.09.2024 17:36Du unterstellst, dass Coding immer selbsterklärend und leicht verständlich ist oder gemacht werden kann. Das halte ich für eine Illusion. Zum einen gibt es komplexe Zusammenhänge, die sich auch bei guter Modularisierung nicht immer perfekt überschaubar gestalten lassen, zum anderen hat man als Programmierer einen Plan im Kopf, wie man das zu lösende Problem mit einem Code abdecken möchte.Na, WAS das Coding macht, das steht ja im Coding.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Ich weiß, dass es eine entsprechende Programmierrichtlinie der SAP gibt, unterstütze sie aber nur aber einer gewissen Mindestanzahl an Feldern. Eine übersichtliche Handvoll Parameter in eine rasch definierte Struktur zu kapseln, fügt einfach einen Wasserkopf hinzu, der die Übersichtlichkeit verringert, anstatt sie zu verbessern.Ralf hat geschrieben:Bei Einzelfeldern. Ich würde erwarten, dass man solche Felder in einer Struktur übergibt
Natürlich gibt es auch den Fall, dass man reichlich Werte übergeben muss. Sowas hatte ich gerade bei meinem ersten Abenteuer "Buchen in FI". Da habe ich mich gefragt, ob ich dem FB BAPI_ACC_DOCUMENT_POST auch die Buchungsschlüssel mit übergeben muss. (Dass es sich dabei um einen FB und nicht um eine statische Methode handelt, ist für die Frage, über die wir hier gerade diskutieren, unerheblich.) Die Antwort hat sich prompt ergeben: Die Strukturen bzw. Tabellenparameter, in denen der FB seine Eingabeparameter erwartet, haben keine Spalte für die Buchungsschlüssel. Damit wäre das geklärt. 😀
Vielleicht werden die Belege ja erst zusammengesetzt, um später in die Datenbank geschrieben zu werden. Klar kann man dann anfangen zu schauen und zu wühlen, welche Spalten da wie ermittelt werden oder welcher Verbuchungsbaustein nachher aufgerufen wird. Aber das ist einfach mehr Aufwand, als wenige Worte Überschrift zu haben, die mir (auch als jemand, der das Programm nicht kennt und selbst womöglich einen ganz anderen Programmierstil hat) auf einen Blick zeigt, worum es in dem folgenden Programmabschnitt geht. Ich will schnell den Programmabschnitt finden, der mich interessiert, und nicht durch was anderes aufgehalten und aus meinen Gedanken gerissen werden.Ralf hat geschrieben:Du meinst sowas wie "LOOP AT einkaufsbelege ASSINING...."? Das wäre selbsterklärend.
Es ist auch nicht immer ganz einfach, Felder und Routinen mit den maximal 30 Zeichen treffend zu beschreiben. Ich gehöre zu den wenigen, die dieses Limit gerne auszuschöpfen pflegen, anstatt meine Felder lv_zahl zu nennen. Dennoch ist es nicht immer ganz einfach, es sei denn, ich kürze in einer Art und Weise ab, die sich einem anderen Leser nicht unbedingt sofort erschließt.
Wie war das mit dem Räderdrehmoment und der Motorsteuerung? 😜Ralf hat geschrieben:Ungenauigkeiten in der Kommunikation sind eine häufige Fehlerursache. Darum wird man sowas bei mir nicht finden.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Du meinst, mit einer Methode, die z. B. do_sekantenverfahren( ) heißt? 😉black_adept hat geschrieben: ↑13.09.2024 11:50Das möchte ich voll unterstüzten. @Ralf: Stell dir vor du hast die Aufgabe die Ausgabe einer Funktion hinreichend zu optimieren. Du hast die grobe Wahl zwischen Intervallhalbierung, Sekantenverfahren oder Newtonverfahren ( weil du die 1. Ableitung der Funktion genähert abbilden kannst ). Ehrlich gesagt glaube ich nicht, dass > 50% der Entwickler jedes dieser Verfahren allein am Coding erkennen könnten.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Da habe ich gesagt, dass ich von der Materie nichts verstehe.DeathAndPain hat geschrieben: ↑13.09.2024 13:22Wie war das mit dem Räderdrehmoment und der Motorsteuerung? 😜Ralf hat geschrieben:Ungenauigkeiten in der Kommunikation sind eine häufige Fehlerursache. Darum wird man sowas bei mir nicht finden.
Ich denke, zu dem Thema ist alles gesagt.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
0
Antw.
Antw.
2218
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.
14927
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.
3366
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.
5535
Views
Views
4
Antw.
Antw.
9732
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1103
vor 2 Tagen von DeathAndPain 4 / 1103
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1103
vor 2 Tagen von DeathAndPain 4 / 1103