ich schließe mich der Frage an.ZF_SAPler hat geschrieben: ↑29.05.2024 21:16Hallo,
Ich bin jetzt seit 4.5 Jahren SAP Entwickler.
Meine Themen sind:
ABAP OO
SAP Erweiterungen
Formulare
Workflows
CDS Views
Fiori Elements
RAP
Und das alles quer durch alle Kernmodule.
Nun möchte ich mich etwas breiter aufstellen, aber ixh weiß nicht was genau.
Mehr Basis? BTP?
Ein Modul lernen?
Ich würde schon gerne ein SAP Architekt in der Zukunft sein wollen. Gibt es denn einen technischen SAP Architekt? Was muss ich dafür alles können oder lernen? Ich brauche unbedingt Leute die mir hierbei weiterhelfen können oder vielleicht in der selben Lage sind.
Ich bin dankbar für jeden Tipp
PS: Ich mag meinen Beruf sehr als Entwickler, möchte aber nicht vielleicht irgendwann auf der Strecke bleiben, wenn es immer mehr Tools gibt’s, wo man kaum mehr programmieren muss
Folgende Benutzer bedankten sich beim Autor rob_abc für den Beitrag (Insgesamt 2):
DeathAndPain • gtoXX
Naja, wenn es "nur" die nicht Verwendung von 7.40-Syntax wäre, wäre die Welt ja in Ordnung.DeathAndPain hat geschrieben: ↑05.06.2024 12:25...
Wenn ich mir anschaue, wie mies die meisten Leute programmieren, kann ich mir kaum vorstellen, dass es bald keinen Bedarf an guten Entwicklern mehr geben wird. Wichtig ist, dass Du das, was Du kannst, gut kannst, anstatt von allem ein bisschen zu können aber nichts richtig, so dass alles, was Du machst, ein Stück weit improvisiert statt professionell ist. Selbst wenn man es auf die einfache Anforderung herunterbricht "7.40-Syntax voll ausschöpfen", müssen eigentlich alle ABAP-Entwickler, die ich außerhalb dieses Forums hier zu sehen bekommen habe, die Segel streichen.
...
Also wenn du nicht Einstein-Gene in dir hast halte ich das für eine maßlose Selbstüberschätzung, gehe noch ein wenig in dich und prüfe ob du das wirklich beherrschst oder es hauptsächlich lesen kannst
Es steht nirgendwo wie tief das Themenwissen geht, daher sehe ich weder eine Ein- noch Überschätzung in der Aussage.
Das ist Wunschdenken von Vertrieblern: Hirnschmalz durch das Ziehen bunter Linien zu ersetzen. Lachhaft, aber nichts neues. Marx träumte auch davon, dass Maschinen den Menschen die Arbeit gänzlich abnehmen würden. Stattdessen erhöht sich die Komplexität.
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag (Insgesamt 2):
rob_abc • DeathAndPain
So ist es. In der aktuellen Ausgabe der c't wird berichtet, wie die ganzen überhypten KI-Aktien gerade abstürzen, weil die Anleger feststellen, dass den immensen Investitionen keine nennenswerten Erträge gegenüberstehen. Die KI-Firmen (wie nvidia) sind zwar alle sehr profitabel, erwirtschaften aber nicht annähernd das, was die Börse von ihnen erwartet hat.
Ich halte es für essenziell, als Entwickler das Modul zu kennen, in dem man entwickelt. Zu verstehen, was man tut und warum, ist das, was einen Entwickler von einem Programmierer unterscheidet. Man kann ein Programm nicht richtig designen, wenn man die Umstände in dem Modul, für das man entwickelt, nicht wirklich verstanden hat. Ein Entwickler muss in meinen Augen immer auch Berater für das Modul sein, in dem er entwickelt, damit er eine Vorstellung hat, welche Zusammenhänge vorliegen, welche Lösungsoptionen sich daraus ergeben und wie diese zu bewerten sind.tar hat geschrieben: ↑31.08.2024 01:12Zumindest 1-2 Module näher zu kennen, ist sicher nicht verkehrt - das kommt aber mit der Entwicklungsarbeit automatisch. Als Entwickler ist das Modul aber letztlich egal, denn letztlich liegen alle Daten in irgendwelchen DB-Tabellen, mit denen hantiert werden will.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
tar • gtoXX
Warum eigentlich? 😃
Das ist wie mit dem SAPGui. Soweit ich mich an die ursprünglichen Ankündigungen und Gerüchte erinnere, hätte es schon Version 7.00 nicht mehr geben dürfen, da "die Zukunft ja webbasiert" war. Man hat sich aber zuerst doch nicht dazu durchringen können, und inzwischen scheint die SAP begriffen zu haben, was für ein Juwel (und komparativen Konkurrenzvorteil) sie an ihrem auf ihre Software maßgeschneiderten SAPGui hat anstelle eines Browsers, der auf das Browsen im Netz optimiert ist.ralf.wenzel hat geschrieben: ↑02.09.2024 09:55Ich kann gar nicht zählen, wie oft mir angekündigt wurde, dass meine berufliche Tätigkeit als SAP-Applikationsentwickler von endlicher Notwendigkeit ist. Das wird bald nur noch zusammengeklickt, das machen die Inder billiger, das machen die Rumänen NOCH billiger, jetzt ist es die KI. Schon in der Ausbildung war das ein Thema, inzwischen arbeite ich über 30 Jahre in diesem Beruf und ein Ende ist nicht absehbar.
Tatsächlich ist es ja sogar so, dass selbst richtig schlechte Entwickler sich nach wie vor in der Branche halten können, weil sich kaum Alternativen finden. Ich bekomme immer wieder Programme neuesten Datums zu sehen, die mit Programmiertechniken geschrieben wurden, die von der SAP schon im Jahre 2010, als ich auf das HCM-Modul umgestiegen bin, als veraltet eingestuft worden sind. Natürlich sind diese Programme zudem so geschrieben, dass sie selbst dann noch als pfuschlig zu bewerten sind, wenn man sie mit den Programmiermaßstäben jener antiken Zeiten bewertet.ralf.wenzel hat geschrieben: ↑02.09.2024 09:55Nichts davon ist eingetreten. Ich habe so viel Nachfrage wie nie zuvor, die Zeit der Dreimonatsverträge ist lange vorbei, ich bekomme Jahresverträge mit Option aufs Folgejahr (für die, die das nicht wissen: Ich bin selbstständig). Selbst wenn eine KI Coding bauen könnte, gehört dazu immer noch die fachlich/technische Beratung dazu, für die wir unerlässlich sind (das ist übrigens der Grund, warum "Codingknechte" aus irgendwelchen fernen Ländern keinen Stich gesehen haben).
An dieser Stelle denke ich, dass die Wahrheit in der Mitte liegt. Nicht jeder, der einen Bereich kennt, muss alle Teile dieses Bereichs ausschöpfen. ABAP OO ist zunächst mal Programmieren mit Klassen und Methoden statt Formroutinen und Funktionsbausteinen. Natürlich gibt es noch viele weitere Funktionalitäten, die man nutzen kann. Aber nicht jeder braucht alles. Ich zum Beispiel habe zwar Vererbung und Objekte verstanden, brauche aber in der Praxis praktisch nur abstrakte und finale Klassen, weil sich mir in meiner Praxis keine so komplexen Probleme stellen, dass Instanziierungen und Vererbungen mir Vorteile brächten. Auch bei den Programmen anderer sehe ich in aller Regel, dass von jeder Klasse nur ein einziges Objekt erzeugt und dann damit gearbeitet wird. Dann ist die ganze Objekterzeugung aber nur ein Wasserkopf. In diesem Fall führt eine abstrakte Klasse, die man nicht instanziieren muss, zu einem kürzeren und zugleich besser lesbaren Programm.ralf.wenzel hat geschrieben: ↑02.09.2024 09:55Anderes Beispiel: Was heißt "ABAP OO"? Mit welchen objektorientierten Techniken hast du WIRKLICH Erfahrung? Welche Entwurfsmuster kennst du (wenn du nicht weißt, was das ist, streiche den Punkt aus deiner Liste)?
Gute Frage. Irgendwie beschäftige ich mich in meiner Freizeit zunehmend mit anderen Dingen, die mit ABAP nix zu tun haben 😉
Öhm.... Nein.DeathAndPain hat geschrieben: ↑03.09.2024 21:04OO ist zunächst mal Programmieren mit Klassen und Methoden statt Formroutinen und Funktionsbausteinen.
Öhm... doch.ralf.wenzel hat geschrieben: ↑03.09.2024 22:12Öhm.... Nein.DeathAndPain hat geschrieben: ↑03.09.2024 21:04OO ist zunächst mal Programmieren mit Klassen und Methoden statt Formroutinen und Funktionsbausteinen.
Tatsä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.