Umstieg auf ABAP Objects
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Hallo zusammen,
bei uns im Betrieb sind derzeit die allermeisten Entwicklungen prozedural umgesetzt. Die paar objektorientierten Sachen, die es gibt, wurden von externen Mitarbeitern gemacht. Intern ist nur theoretisches Wissen über Objektorientierung vorhanden.
Meine Frage ist nun: wie geht man am besten vor, um die interne Mannschaft in Sachen Objektorientierung voranzubringen. Wenn wir lediglich mit dem Wissen aus dem ABAP OO Grundkurs einfach drauflos machen, habe ich die Befürchtung, dass durch schlechtes Design Programme entstehen, die am Ende keiner mehr versteht.
Kann jemand aus seinem Unternehmen berichten, wie ihr vorgegangen seid bei der Einführung von ABAP OO? Welche Erfahrungen habt ihr gemacht? Hat OO sich bewährt?
Ganz vielen Dank schon mal für jeden Tipp!
Viele Grüße
ann_bine
bei uns im Betrieb sind derzeit die allermeisten Entwicklungen prozedural umgesetzt. Die paar objektorientierten Sachen, die es gibt, wurden von externen Mitarbeitern gemacht. Intern ist nur theoretisches Wissen über Objektorientierung vorhanden.
Meine Frage ist nun: wie geht man am besten vor, um die interne Mannschaft in Sachen Objektorientierung voranzubringen. Wenn wir lediglich mit dem Wissen aus dem ABAP OO Grundkurs einfach drauflos machen, habe ich die Befürchtung, dass durch schlechtes Design Programme entstehen, die am Ende keiner mehr versteht.
Kann jemand aus seinem Unternehmen berichten, wie ihr vorgegangen seid bei der Einführung von ABAP OO? Welche Erfahrungen habt ihr gemacht? Hat OO sich bewährt?
Ganz vielen Dank schon mal für jeden Tipp!
Viele Grüße
ann_bine
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Wenn in Eurem Betrieb " lediglich mit dem Wissen aus dem ABAP OO Grundkurs" besteht, sollte man vielleicht weitere, aufbauende Kurse den Mitarbeiter anbieten.ann_bine hat geschrieben:Hallo zusammen,
bei uns im Betrieb sind derzeit die allermeisten Entwicklungen prozedural umgesetzt. Die paar objektorientierten Sachen, die es gibt, wurden von externen Mitarbeitern gemacht. Intern ist nur theoretisches Wissen über Objektorientierung vorhanden.
Meine Frage ist nun: wie geht man am besten vor, um die interne Mannschaft in Sachen Objektorientierung voranzubringen. Wenn wir lediglich mit dem Wissen aus dem ABAP OO Grundkurs einfach drauflos machen, habe ich die Befürchtung, dass durch schlechtes Design Programme entstehen, die am Ende keiner mehr versteht.
Kann jemand aus seinem Unternehmen berichten, wie ihr vorgegangen seid bei der Einführung von ABAP OO? Welche Erfahrungen habt ihr gemacht? Hat OO sich bewährt?
Ganz vielen Dank schon mal für jeden Tipp!
Viele Grüße
ann_bine
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Es gibt auch (theoretische) OO-Kurse abseits von ABAP um das Grundkonzept hinter dieser Art des Programmierens zu Erläutern.
Überlegenswert wäre auch "frisches Blut" ins Unternehmen zu holen. Studiums- oder Abituranten/Maturanten von technischen Unis/HTLs lernen die Grundkonzepte bereits im Unterricht. Ihr müsstet sie lediglich an die Programmiersprache (und ihre Eigenheiten) heranführen. Junge Leute sind da sehr flexibel. Im Gegenzug kann die ältere Mannschaft etwas von OO lernen.
Zumindest war es bei mir so wie ich angefangen hab zu Arbeiten.
lg ADT
Überlegenswert wäre auch "frisches Blut" ins Unternehmen zu holen. Studiums- oder Abituranten/Maturanten von technischen Unis/HTLs lernen die Grundkonzepte bereits im Unterricht. Ihr müsstet sie lediglich an die Programmiersprache (und ihre Eigenheiten) heranführen. Junge Leute sind da sehr flexibel. Im Gegenzug kann die ältere Mannschaft etwas von OO lernen.
Zumindest war es bei mir so wie ich angefangen hab zu Arbeiten.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Das Grundkonzept haben die Mitarbeiter ja schon mit auf den Weg bekommen.
Jetzt geht es der Firma wohl darum, OO korrekt, sinnvoll und professioneller anzuwenden.
Ich habe mal in einem Projekt bei einerm Add-On Anbieter mitgearbeitet, wo es um "100% ABAP OO Programmierung" ging.
OO maessig schienen es die drauf zu haben, aber im Hintergrund wird immer noch ABAP programmiert. Und dort sah es ziemlich jaemmerlich aus.
Methoden mit 25 Zeilen Coding was ich mit einer Zeile und REGEX erschlagen habe. Errorhandling, sogut wir gar nicht vorhanden.
Bei ABAP OO ist es wichtig, dass man OO UND ABAP beherrscht. Nur mit OO kommt man da nicht weit.
Mir kommt es so vor, als ob ein ABAP Programmierer eher ABAP OO lernt, als ein JAVA OO Programmierer traditionelles ABAP.
Ich finde, es ist auch wichtig, dass man Leute (auch alte ABAPler) findet, die Interesse am ABAP OO haben.
Dann evtl. etwas JAVA OO lernen (obwohl ich mit JAVA nie warm werde) , weil das fuer mich doch pureres OO als ABAP OO ist.
Es gibt jedemenge freier Kurse wo man das OO Programmieren lernen kann.
Nur mal als Beispiel http://www.OPENHPI.de mit "JAVA fuer Einsteiger".
Jetzt geht es der Firma wohl darum, OO korrekt, sinnvoll und professioneller anzuwenden.
Ich habe mal in einem Projekt bei einerm Add-On Anbieter mitgearbeitet, wo es um "100% ABAP OO Programmierung" ging.
OO maessig schienen es die drauf zu haben, aber im Hintergrund wird immer noch ABAP programmiert. Und dort sah es ziemlich jaemmerlich aus.
Methoden mit 25 Zeilen Coding was ich mit einer Zeile und REGEX erschlagen habe. Errorhandling, sogut wir gar nicht vorhanden.
Bei ABAP OO ist es wichtig, dass man OO UND ABAP beherrscht. Nur mit OO kommt man da nicht weit.
Mir kommt es so vor, als ob ein ABAP Programmierer eher ABAP OO lernt, als ein JAVA OO Programmierer traditionelles ABAP.
Ich finde, es ist auch wichtig, dass man Leute (auch alte ABAPler) findet, die Interesse am ABAP OO haben.
Dann evtl. etwas JAVA OO lernen (obwohl ich mit JAVA nie warm werde) , weil das fuer mich doch pureres OO als ABAP OO ist.
Es gibt jedemenge freier Kurse wo man das OO Programmieren lernen kann.
Nur mal als Beispiel http://www.OPENHPI.de mit "JAVA fuer Einsteiger".
Wichtig wäre tatsächlich professionelle Anleitung (Kurse) und Begleitung!
Was ich auch sinnvoll finde, sind regelmäßige Treffen (Einmal pro Woche zwei Stunden), in denen sich alle Entwickler an einen Tisch setzen und die aktuellen Probleme diskutieren, Lösungen vorstellen oder vorbereitete Aufgabe präsentieren. So kann man die ganze Abteilung voran bringen.
Das wichtigste meiner Meinung sind diese drei Dinge:
- Üben.
- Tun.
- Machen.
Nur dadurch stößt man wirklich auf die Probleme und Schwierigkeiten, die man auch im wahren Leben hat. Wenn man sich nur in einen Kurs setzt und die Zeit mit "Hmm" und "Ach das ist ja interessant" absitzt, bringt das wenig.
Wichtig ist auch das Ziel (wie so oft)...
- Was will ich mit der OO-Programmierung erreichen?
- Sollen neue Programme immer in OO konzipiert werden?
- Wer prüft die Qualität der OO-Programme?
OO bringt viele Vorteile. Aber es ist nicht der heilige Gral. Gerade bei relativ einfachen Reports ist es egal, ob diese OO programmiert sind, oder prozedural.
Wobei man gerade solche Reports gut als Übungsobjekt nutzen kann... Der Nutzen liegt dann nicht am Programm sondern bei der Weiterbildung.
Was ich auch sinnvoll finde, sind regelmäßige Treffen (Einmal pro Woche zwei Stunden), in denen sich alle Entwickler an einen Tisch setzen und die aktuellen Probleme diskutieren, Lösungen vorstellen oder vorbereitete Aufgabe präsentieren. So kann man die ganze Abteilung voran bringen.
Das wichtigste meiner Meinung sind diese drei Dinge:
- Üben.
- Tun.
- Machen.
Nur dadurch stößt man wirklich auf die Probleme und Schwierigkeiten, die man auch im wahren Leben hat. Wenn man sich nur in einen Kurs setzt und die Zeit mit "Hmm" und "Ach das ist ja interessant" absitzt, bringt das wenig.
Wichtig ist auch das Ziel (wie so oft)...
- Was will ich mit der OO-Programmierung erreichen?
- Sollen neue Programme immer in OO konzipiert werden?
- Wer prüft die Qualität der OO-Programme?
OO bringt viele Vorteile. Aber es ist nicht der heilige Gral. Gerade bei relativ einfachen Reports ist es egal, ob diese OO programmiert sind, oder prozedural.
Wobei man gerade solche Reports gut als Übungsobjekt nutzen kann... Der Nutzen liegt dann nicht am Programm sondern bei der Weiterbildung.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Kauft euch einen guten Coach ein, der OO rauf und runter kann, mit Design Patterns und Abstraktion. Der wird eine Weile (im Zweifel eine längere Weile) dafür bezahlt, die internen Entwickler darin anzuleiten, gute OO Applikationen zu designen.
Damit haben die meisten meiner Kunden die besten Erfahrungen gemacht.
Damit haben die meisten meiner Kunden die besten Erfahrungen gemacht.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
3827
Views
Views
6
Antw.
Antw.
5749
Views
Views
6
Antw.
Antw.
4431
Views
Views
11
Antw.
Antw.
11819
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 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152
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 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152