gelöst Gehaltsvorstellungen SAP ABAP-Entwickler

[zzcpak]

Ralf *wieso survival???

na das Bild von dir in deiner Signatur. Auf micht wirkt es
- als kämst du geradewegs von einem Survival-Training in der Eifel
- oder hättest eine Nebenrolle in einem Zombie-Apokalypse-Film (tapferer Familienvater, der grimmig den Untoten entgegenwirft, um seine Familie zu retten)
- oder als hättest du gerade eine Nacht über 20-jährigem ABAP-Coding im Cobol-Format verbracht

(sorry, aber das musste jetzt mal gesagt werden, hab ich echt erschrocken *gg*)

Mit den Kundenansprüchen hast du sicherlich recht. Gleichwohl ich vermute/befürchte, dass diese mit S/4HANA wieder sinken werden, weil die Nachfrage nach "Fachleuten" wieder so groß sein wird.

[ralf.wenzel]

Nein, die Ansprüche werden nicht sinken, weil die Ansprüche, die S/4 an Entwickler stellt, deutlich höher sind.


Ralf *das ist eines meiner FREUNDLICHEN Fotos!

[zzcpak]

lol, dann will ich nicht sehen, wie du böse drein guckst.

Ich denke schon, dass die Ansprüche wieder sinken werden, einfach aus dem Grund, weil nicht genügend Know-How vorhanden ist.
Ein Beispiel dafür bin ich selbst, da ich aktuell zu einem Kunden wechsle, der S/4HANA im Einsatz hat. Ich wurde beim Vorstellungstermin noch nicht einmal gefragt, ob ich Erfahrungen darin hätte. Ich vermute, zur Zeit erwarten viele Firmen das auch gar nicht, zumindest die mit realistischen Vorstellungen.

[ralf.wenzel]

Die wissen, dass die JETZT keine Leute mit S/4-Know-how finden. Aber in 3 Jahren kriegt man kaum noch ein Projekt, wenn man das nicht vorweisen kann.

In 3 Jahren sehr wir schlauer


Ralf

[DeathAndPain]

Dennoch, Ralf, selbst wenn wir nur von ABAP-Kenntnissen in R/3 ausgehen, denke ich, dass Deine Haltung überzogen ist. Versuche mal jemanden zu finden, der Deine Fragen beantworten kann. Da wirst Du auf dem Markt lange suchen müssen; solche Leute gibt es nicht viele. Und die, die Du am Ende findest, sind Seniorberater mit stolzen Gehaltsvorstellungen (die sie auch durchsetzen können, eben weil man kaum gute Leute findet).

Wenn Du einen Juniorberater hast, der ziemlich frisch von der Akademie kommt und sich mit 45.000 - 50.000 zufriedengibt, dann sind die von dem Threadersteller genannten Kenntnisse eine ganz ordentliche Grundlage, auf der man aufbauen kann. In vielen Firmen werden diese Kenntnisse auch wunderbar ausreichen. In Zeiten, in denen einige noch nicht mal die 7.40-Syntax nutzen können, braucht nicht jeder S/4 HANA. Zumal ein S/4 HANA-Server angesichts der Speicherpreisentwicklung der letzten Jahre auch einiges kostet und viele Firmen auch noch mit klassischen Festplatten (ggf. in SSD-Technik) zufrieden sind. Im übrigen ist es auch eine Modulfrage: Z.B. HCM gibt es noch gar nicht für S/4 HANA, sondern soll 2023 überhaupt erst kommen!

Natürlich hast Du recht: Was ein Kandidat taugt, hängt wesentlich davon ab, wie er mit Problemen umgeht, auf die er die Antwort nicht aus dem Ärmel schütteln kann. Aber diese Aspekte von Bewerbungsgesprächen sind nicht Gegenstand dieses Threads hier.

[ralf.wenzel]

Ich will ja niemanden einstellen. Und wer mich fragt, wen er einstellen soll, der bekommt eine Antwort nach meinen Maßstäben.

Ralf

[DeathAndPain]

Das hat der Threadersteller aber nicht getan.

Und Du würdest dann "nach Deinen Maßstäben" niemanden finden. Jedenfalls nicht annähernd in der Gehaltsregion, die dem Threadersteller vorschwebt.

[nickname8]

ABAP 00

Ohne Worte.

Ich würde vorschlagen, dran zu arbeiten, damit da schnell ein ABAP OO 1.0 draus wird.

[black_adept]

Dennoch, Ralf, selbst wenn wir nur von ABAP-Kenntnissen in R/3 ausgehen, denke ich, dass Deine Haltung überzogen ist. Versuche mal jemanden zu finden, der Deine Fragen beantworten kann. Da wirst Du auf dem Markt lange suchen müssen; solche Leute gibt es nicht viele. Und die, die Du am Ende findest, sind Seniorberater mit stolzen Gehaltsvorstellungen (die sie auch durchsetzen können, eben weil man kaum gute Leute findet).

Oder solche, die den Kopf darüber schütteln warum jemand IMMER eine Erzeugungsmethode verwendet anstatt dies fallspezifisch nur dann zu machen, wenn es angesagt ist, da man sich durch (statische) Factorymethoden eben manchmal auch selbst nachher im Wege steht.

[ralf.wenzel]

Wann sollte man sich damit im Wege stehen?


Ralf

[black_adept]

Wann sollte man sich damit im Wege stehen?f

Wegen der Vererbung.
Dann, wenn man z.B. diverse Implementierungen eines Interfaces bereitstellen möchte, von denen einige über Vererbung ( evtl. sogar eine Basisimplementierung - aber halt nicht zwingend ) miteinander verknüpft sind, die sich aber in ihren Konstruktoren deutlich voneinander unterscheiden. Da eine Factoryklasse statisch ist müsste diese die Obermenge der Parameter aller (auch abgeleiteten) Implementierungsklassen enthalten, sowie einen Hinweis welche der Klassen denn nun gerade erzeugt werden muss oder die Schnittstelle müsste sehr! abstrakt aufgebaut sein oder Unterklassen mit abweichenden Parametern müssten einerseits eine eigene, anders benannte Erzeugungsmethode bereitstellen und zusätzlich dafür sorgen, dass die eigene Erzeugung mit der vererbten Factorymethode fehlschlägt.
Es gibt hinreichend viele Fälle, wo ich solche Factorymethoden auch gerne bereit stelle - gerade in dem von dir genannten Kontext, dass "unbedingt noch xxx während der Erzeugung gemacht werden muss". Das geht aber meistens nur auf Kosten der Lesbarkeit weil ich gezwungen bin die Konsistenz der übergebenen Parameterkombinationen zusätzlich zu überwachen was bei eigenen Konstruktoren halt über die Schnittstelle geregelt werden kann. Und ein "Weil ich zu oft erlebt habe, dass man vor einer Instanziierung dann doch noch etwas prüfen will" reicht mir dann halt nicht aus um mich durch die Beschränkungen der Factorymethode einengen zu lassen und ein "die ich an funktionalen Operandenpositionen einsetzen kann" kann ich oft genug durch den NEW-Operator ersetzen

[deejey]

verstehe kein Wort

[DeathAndPain]

Ich habe eine grobe Vorstellung davon, wovon die beiden reden. Was ich nicht verstehe, ist, weshalb Ralf offenbar die für diesen Zweck in OO vorgesehene Constructor-Methode durch eine selbstgebastelte Erzeugungsmethode ersetzen möchte. Wird dadurch aus OO nicht doch 00? Was ist der Vorteil?

[deejey]

00

[ralf.wenzel]

Ich kann die Argumentation von Stefan nachvollziehen, wobei meine Konstruktoren in der Regel keine Parameter haben oder sie sind innerhalb der Vererbungshierchie dieselben. Damit ergibt sich das von ihm beschriebene Problem nicht, andernfalls würde ich auf dieses, von mir bevorzugte, Konstrukt verzichten.

Ich habe halt den zentralen Gedanken, dass ein Objekt sich selbst verwalten sollte. Und beziehe dabei die Instanziierung mit ein. Ich verzichte dabei nicht auf den Konstruktor, für manche Sachen ist es im Konstruktor einfach zu spät.

Das mit der Programmierung auf Vorrat mache ich bei Attributen auch: Ich mag öffentliche RO-Attribute nicht, es gibt IMMER GET-Methoden, weil sich oft herausstellt, dass für manche Lesezugriffe auf Attribute doch ein bisschen Logik notwendig ist. Auch wenn das in 9 von 10 Fällen nicht der Fall ist.


Ralf