Maschinelle Lohnsteuerberechnung für 2019

Re: Maschinelle Lohnsteuerberechnung für 2019

Welchen Teil von "generische Persistenzschicht" hast du nicht verstanden?

Den "Ich-werfe-mit-Fremdwörtern-um-mich-anstatt-zu-sagen-was-ich-meine-weil-klingt-cooler"-Teil.

Eine generische Persistenzschicht dient dazu, von der physischen Ebene zu entkoppeln. Sowas kann man machen, damit man z.B. die zugrundeliegende Datenbank austauschen kann, ohne den Code anpassen zu müssen. Da ABAP das aber schon von sich aus macht, indem man eben nicht datenbankspezifisches Native SQL, sondern ABAP-einheitliches Open SQL programmiert, ist das hier witzlos.

Du willst eine Methode machen, die die Argumente des SELECTs an den SELECT weiterreicht. Klingt nützlich... Dass Du damit auch Clustertabellen abdecken willst, klingt nicht wie eine überzeugende Rechtfertigung. Vor wieviel Jahren hat die SAP die Entscheidung getroffen, den Ansatz der Clustertabellen nicht weiter zu verfolgen und eine nach der anderen auf transparente Tabellen umzustellen? Und war nicht die schlechteste Entscheidung!

Davon abgesehen rechtfertigt das eine Promille meiner Datenbankzugriffe, das auf Clustertabellen geht, nicht den ganzen Fax mit dem Kapseln von SELECTs in Methoden, die den SELECT machen. Da nehme ich an den wenigen Stellen, an denen ich Clustertabellen brauche, lieber die von der SAP gebotenen Funktionsbausteine (oder gar Makros, sowas gibt's - da sieht man mal, wie alt der Clusterkram ist). Performance pflegt beim Zugriff auf Clustertabellen ohnehin kein Thema zu sein, denn aus Clustertabellen zu lesen ist von Hause aus langsam, und wofür man Performance braucht, dafür nimmt man keine Clustertabelle. Noch nicht einmal die SAP.

Re: Maschinelle Lohnsteuerberechnung für 2019

DeathAndPain hat geschrieben:Sobald man eine Sammlung zusammengehörender Daten lesen möchte, zwischen denen ein logischer Zusammenhang besteht, so dass man solch Sammlung häufiger benötigt, macht eine Kapselung Sinn. Aber nicht für den einzelnen SELECT.

An diesen Satz musste ich gerade denken, weil ich Unit-Tests schreibe. Frage an dich: Wie mockst du einen DB-Zugriff, wenn du selbigen nicht kapselst? Schon um des Mocking willen lohnt es sich, den SELECT in eine eigene Methode zu schreiben. Oder schreibst du keine Unit-Tests? Bist du auch so einer, der einmal F8 drückt und sagt "ist getestet" wenn es nicht dumpt?


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

Nehmen wir an, du willst einen Datensatz von der DB lesen und irgendwas damit tun. Die „tu_irgendwas“-Methode willst du testen. Da Unit-Tests per Definition systemunabhängig sein müssen (damit sie auf jedem System mit jedem Datenstand reproduzierbar dasselbe Ergebnis liefern), kannst du natürlich nicht wirklich einen Satz von der DB lesen, weil potentiell auf jedem System andere Daten stehen und sich Daten ändern können im Laufe der Zeit, was deinen Test invalidiert. Der Test wirft also plötzlich Fehler, obwohl deine Methode noch funktioniert.

Also musst du für den Test dafür sorgen, dass die Testmethode „denkt“, sie lese von der DB. In Wahrheit schiebst du ihr immer dieselben Werte unter, weil du voraussetzt, dass der DB-Zugriff korrekt ist (das ist insbesondere dann der Fall, wenn du eine generische Persistenzschicht verwendest, die ordentlich getestet ist).

Wenn du den SELECT hart ins Coding (und zwar nicht in eine eigene Methode) schreibst, kannst du dem Test keine Daten vorgaukeln, du kannst also keinen Unit-Test schreiben. Dafür musst du ZWINGEND irgendwie dafür sorgen, dass du den DB-Zugriff mocken kannst. Z. B. indem du gegen ein Interface programmierst (hinter dem beim Test eine andere Klasse steht) oder indem du die zu Klasse mit dem SELECT erbst und den DB-Zugriff redefinierst (so mache ich das normalerweise). Aber eben nur den, weil den Rest willst du ja testen. Das echte, produktive Coding, keine Test-Redefinition).


Ralf *warum muss ich meiner Frau sowas nicht erklären? Ist sie ein Freak?

Re: Maschinelle Lohnsteuerberechnung für 2019

Du schreibst mal eben in die VBAK???? OMG

Wieso muss mein SELECT erkennen, dass der Test auf ihn zugreift? Dafür hab ich doch die lokale Subklasse, die ich aufrufen kann.


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

deejey hat geschrieben:

ralf.wenzel hat geschrieben:Du schreibst mal eben in die VBAK???? OMG

Wieso muss mein SELECT erkennen, dass der Test auf ihn zugreift? Dafür hab ich doch die lokale Subklasse, die ich aufrufen kann.

na einfach reinbratzen in die VBAK, ist doch das Entwicklungssystem, ausserdem werden sie eh wieder entfernt automatisch beim Beenden der Testunit.

Wie funktioniert das mit den lokalen Subklassen? Sie erben alles, jetzt überschreibst du wohl die methode select_vbak der Unterklasse mit ergebnis_vbak = .....?

Also, wenn ich eine Testklasse anlege (die per Definition eine lokale Klasse ist), baue ich dazu eine lokale Hilfsklasse. Diese lokale Hilfsklasse erbt von der Klasse mit der zu testenden Methode, weshalb ich sie überschreiben kann. Geht natürlich mit finalen Klassen nicht.

Welcher schlafmützige Idiot ist eigentlich auf die Idee gekommen, das "Final"-Flag in der SE24 vorzubelegen? Eine Klasse sollte per Default NIE final sein, das ist eine Eigenschaft, die man explizit einschalten sollte, wenn es Gründe gibt, Vererbung zu verhindern. Bei jedem Kunden ärgere ich mich über finale Klassen, für deren Finalität es keine Gründe gibt. "Das war schon angehakt", höre ich dann..... *tob

Bei finalen Klassen sollte man dann (sollte man eigentlich eh, aber da ganz besonders) darauf achten, dass man alles hinter einer Schnittstelle versteckt, damit man die Implementierung austauschen kann.

deejey hat geschrieben:Ich muss mich mehr mit dem OO-Krempel beschäftigen

Definitiv

Das ist gar nicht so schwer -- Ich hab schon genügend Leuten, die immer gesagt haben, dass sie OO einfach nicht verstehen, das SO erklärt, DASS sie es verstehen. Weil ich es anders erkläre als diese Standardabsätze in Büchern und im Netz ("Angenommen, Sie haben fünf Fahrzeuge, Auto, Mofa, ...."). Die haben mich immer geärgert, weil die keinen Bezug zur Praxis haben. Verstanden habe ich es erst, als die Praxis mich das lehrte.

Und gerade jetzt habe ich wieder einen Auftrag reinbekommen, dass ich Entwickler in OO coachen soll. Sind tolle Aufträge, ich quatsche über OO und kriege sogar Geld dafür. Ich darf nur meinen Kunden nicht sagen, dass ich das auch ohne Bezahlung gern mache, weil ich das Thema total spannend finde LOL


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

black_adept hat geschrieben:Da das ja eins deiner Lieblingsargumente ist. Mich würde hier im Forum mal interessieren wie viele der Forumsteilnehmer tatsächlich solche Unit-Tests schreiben (müssen/dürfen).

Ich will das, glaube ich, gar nicht wissen. Sonst zerbreche ich wieder irgendwas.....

Weil die anderen nicht dabei waren, als wir neulich essen waren, mein Lieblingsbeispiel: Hier ums Eck sitzt die Firma HAUNI, die baut Automaten zur Zigarettenherstellung. Da kommen mal so eben 25.000 Zigaretten pro Minute aus dem Gerät. Und jede einzelne ist vermessen und gewogen, was die Toleranzwerte überschreitet, fliegt raus.

Wie wollen wir denn Qualität sicherstellen, wenn wir keine Tests schreiben? Warum können wir Qualität nicht verkaufen, obwohl sie ein Wert in sich ist - wir sprechen hier über das zentrale IT-System unserer Kunden! Sollte nicht unser Berufsstolz dazu führen, dass wir ein Ergebnis auf Ingenieur-Niveau produzieren und nicht auf dem Niveau von Skript-Kiddies? Dazu gehören reproduzierbare Tests, für mich ist eine Anwendung ohne solche Tests wie ein Auto mit ungetesteten Bremsen. Ja, ich hab sowas auch schon abgeliefert auf Kundenwunsch, aber so sollten wir nicht arbeiten. Und im Ergebnis war es so, dass die Java-Truppe (für die wir Funktionen geschrieben haben) dann Unit-Tests geschrieben hat, bis ich denen erklärt habe, dass wir das durchaus auch können.

Und ich bin fest entschlossen, sowas zukünftig abzulehnen, weil ich inzwischen aus Erfahrung weiß, wie wichtig solche Tests sind. Weil ich zu oft erlebt habe, dass Leute an irgendwelchen Applikationen herumschrauben und mit dem Arsch einreißen, was ein anderer mit den Händen aufgebaut hat (das klingt wie ein Vorwurf, ist aber keiner - bei der Komplexität heutiger Anwendungen ist das kaum zu vermeiden). Und weil sie dokumentieren, wie eine Klasse verwendet wird und wie nicht. Was ein gültiges Ergebnis einer Methode ist und was nicht. Und welche Fehler mal aufgetaucht sind (wenn man sich die Mühe macht und sie in Unit-Tests nachstellt).

Ich behaupte: Nur SO kann man sicherstellen, dass eine Applikation mit der Zeit wirklich besser wird und nicht nur anders. Weil niemand weiß, ob er nicht versehentlich eine funktionierende Funktion kaputtgemacht hat. Das kann man nur ausschließen, indem man für jede zugesicherte Funktionalität einen Test hat, die sie verifiziert. Und nur so kann man ausschließen, dass eine ungewollte Funktionalität versehentlich funktioniert (per Falsifikation).

Warum, glaubt ihr, guckt die halbe IT-Welt auf ABAP-Entwickler herab? Ja, das ist wirklich so, sprecht mal mit Java- oder C#-Entwicklern, was die für ein Bild von uns haben. "Die können Befehle hintereinanderschreiben, aber von Software-Entwicklung verstehen die nix!" Die preisen ihre Unit-Tests auch ein, weil das für die selbstverständlich ist. So habe ich die zumindest erlebt.

Wie ich einem Ex-Kunden öfters erzählt habe: "Wenn ihr eure (Produkte) so bauen würdet wie eure IT euer SAP-System, der Laden hier wäre längst pleite!". Da hat einer einen Schaltplan vor sich, der vorsieht, dass ein rotes Kabel von A auf einer bestimmten Strecke nach B gelegt wird. Da legt keiner das Kabel diagonal, weil er es zu kurz abgeschnitten hat. Und es nimmt auch keiner ein grünes Kabel, weil rot gerade nicht da ist. Sowas ist Aufwand, den man beim Produkt in Kauf nimmt, beim der zentralen IT-System des Unternehmens aber nicht.

DA müssen wir hin: Dass wir auf einer gegebenen Anforderung (die durchaus agil sein kann - dann fällt wenigstens mal auf, wie teuer agile Projekte wirklich sind, weil die Tests ständig angepasst werden müssen) mit einer ordentlich dokumentierten und getesteten Lösung antworten. Natürlich sage ich nicht "das dauert drei Tage plus einen Tag für Unit-Tests und einen für Dokumentation" (so doof bin ich nicht), sondern dann dauert es fünf Tage, fertig. Und wenn dann einer sagt "ich schaff das in drei", dann stauche ich den vor dem Kunden zusammen, dass ich das auch in zweien schaffe, aber man dann keine professionelle Software bekommt, sondern dahingerotztes Zeugs, das keiner versteht und dessen Funktion keiner sicherstellen kann -- und das unter meinem Niveau ist. In genau diesem Ton. Dann möchte ich mal sehen, was ich da als Antwort kriege.

Ich bin schon aufgestanden wenn ich mich bei Kunden vorgestellt habe mit den Worten "Tut mir leid, so arbeite ich nicht -- suchen Sie sich einen Amateur der so arbeitet". Der Markt ist doch auf unserer Seite. Klar gucken die doof, wenn man sagt (auch ein Zitat von mir aus einem solchen Gespräch) "Ihnen sollte klar sein, dass Sie im Wettbewerb um die besten Entwickler stehen -- und SO kriegen Sie die nicht!", vielleicht kriegt man dann auch mal einen Auftrag oder eine Stelle nicht. Aber von Beidem gibt es genug. Und manchmal schafft man es nicht bis zur Tür, sondern fällt dabei über einen Auftrag a la "dann schlauen Sie doch erstmal unsere Entwickler in OO auf, das ist dann ja schonmal ein Anfang". Auch mein jetziges Projekt, in dem ich jetzt im dritten Jahr tätig bin und mit dem ich einen Haufen Geld verdient habe, bin ich nur, weil ich weiß, wie man Unit-Tests schreibt. Weil explizit jemand gesucht wurde, der DAS kann.

Ich hab schon erlebt, dass wir bei einem Ex-Kunden eine Lösung an neue User (im Ausland) ausrollen sollten und als wir bei der Frage waren, wer das denn nun schulen soll, habe ich geantwortet "Gar keiner, die Anwendung hat eine idiotensichere Anwenderdoku - die lassen Sie übersetzen und die Schulung besteht aus dem Satz 'bitte klicken Sie auf das i-Icon' und fertig" - und der Kunde war glücklich.... Der hat nicht gewusst, dass er die Doku mitbezahlt hat. Aber er war froh, dass er sie hatte, als er sie brauchte, weil sie Geld gespart hat -- statt einem halben Tag, den ich da reingesteckt habe, wäre sonst ein teurer Mitarbeiter deutlich länger ins Ausland geflogen um den Anwendern das Programm zu erklären. Je selbstverständlicher wir Doku und Tests implementieren, umso mehr wird sich durchsetzen, dass das einfach zusammengehört.

Und wenn man das Testen beim Entwickeln im Auge hat, entwickelt man eben auch testbar.


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

Dann sind meine Projekte, die ich mache, Einbildung? Was machst du, wenn du ein Auto brauchst und kein Geld hast? Kaufst du eine Karre, die nicht über den TÜV kommen wird?

Wer kein Geld für gescheite Software hat, soll es lassen. Es kann doch nicht sein, dass eine Firma einmal im Jahr ihre IT-Hardware durchtesten lassen kann, dann für Unit-Tests kein Geld hat.

Jede Wette: Wäre das verpflichtend, wäre Geld da. So wie bei der DSGVO: Vor einem Jahr noch war allen der Datenschutz zu teuer, jetzt plötzlich haben sie alle Geld dafür.

Und in der Gesamtrechnung spart das Zeit und Geld. Problem ist: Projekt ist Projekt und Wartung ist Wartung. Wenn die Wartung sich verteuert und das Projekt billiger ist, freut sich der Projektleiter. Weil er nicht nachhaltig projektiert.


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

black_adept hat geschrieben:

ralf.wenzel hat geschrieben:Dann sind meine Projekte, die ich mache, Einbildung?

Bei normaler Streuung gibt es auch Fälle, wo sich die Praxis mal genau so verhält wie die Theorie es gerne hätte Außerdem hast du ja schon erklärt, dass du nicht der Theorie konforme Projekte ablehnst, so dass deine Filterblase die "schönen" Fälle sind.

Genau, und wenn wir das alle täten, wäre die Welt ein wenig bunter. Übrigens sind mehr und mehr Kunden aufgeschlossen gegenüber gescheiter Entwicklung.

Und wenn mir einer ankommt mit "Bäh, * OO, alles Dreck, mach ich nicht", dann sage ich dem "Alter, du musst doch das Coding der SAP verstehen können. Wenn die OO machen, musst du das lernen. Und wenn die SAP entscheidet, alles nur noch auf chinesisch zu machen, dann müssen wir alle chinesisch lernen -- SAP macht die Regeln für ihr Produkt. Und wenn du das System nicht mehr verstehst, dann hast du den falschen Beruf - sorry. Weil du deine Aufgabe nicht mehr wahrnehmen kannst, das gescheit zu erweitern.". So einen braucht man nur vor ein EWM-System zu setzen und der versteht NICHTS mehr.

Ein Automechaniker (sic!) kann auch nicht sagen "Bäh, * digitale Motorsteuerung, versteht keine Sau, mach ich nicht". Dann zieht der Markt an ihm vorüber. Der würde übrigens auch gar nicht auf die Idee kommen.


Ralf