"Modulpools sind veraltete Technologie"

Da in Klassen keine Dynpros verwendet werden können, sind Modulpools IMHO weit davon entfernt, veraltet zu sein.

ralf.wenzel hat geschrieben:Jein, man kann Dynpros auch problemlos in Funktionsbausteinen verwenden.

Kann man auch in Reports. Aber das war ja nicht deine Frage.

ralf.wenzel hat geschrieben:Folgefrage: Die Aussage "Wir wollen einen Modulpool entwickeln für eine Transaktion. Um Konflikte bei Wartung/Reparaturen möglichst klein zu halten, erstellen wir für jede einzelne Form-Routine einen eigenen Include" würde ich auch gern zur Diskussion stellen.

Ziel ist: Wenn n Entwickler am (dann produktiven Programm) n Fehlerbehebungen/Erweiterungen durchführen, sperren sie sich mit höherer Wahrscheinlichkeit nicht gegenseitig die Objekte weg (insbesondere dann, wenn zum Beispiel parallel zu einer sehr umfangreichen Erweiterung eine kleine Fehlerbehebung notwendig wird).

Das ist ja ok. Wird ja auch von der SE80 so unterstützt.

ralf.wenzel hat geschrieben:Gegenargument: Dabei entstehen dann ggf. Modulpools mit Hunderten von Includes (weil man für jede kleine Werthilfe eine FORM-Routine und dafür ein Include hat).

na und?

Also Modulpools sind meiner Meinung nach noch lange nicht veraltet!

Oder wie soll man sonst eine Funktion erstellen mit ca 30 Dynpros die sowohl RF als auch PbV fähig sind.

Zum Thema Forms&Includes:
Wenn man "passende" FORMS zusammen in "gescheite" Include packt, kann man eine hoche Wartung garantieren.
Ich persönlich hab vor mir grad so ein "Eier legende Woll Milch Sau"-Modulpool, das dank seinen 8 Includes gut Wartbar ist, auch so, das 2 Entwickler total unterschiedliche Sachen parralel implementieren können OHNE sich gegenseitig zu sperren!

Das ausgliedern von Forms in Unterschiedliche Includes kann natürlich auch andere Vorteile bringen wie z.B. mehrere Programme können die selben Includes/Forms daraus nutzen (ok, hat auch Nachteile sowas).

Der Hauptgrund von einigen Includes ist aber meist die Grösse:
Ab einer gewissen Anzahl Codingzeilen kann man ein Includ nicht mehr generieren/aktivieren (meist vorher ist er schon nicht mehr ohne zu stottern scrollbar).

Hab ich eigentlich noch das Richtige Thema, oder bin ich abgekommen?

Forms & Includes.

Theoretisch halte ich die Idee 1 Include für 1 Unterroutine schon für ganz angebracht. Zumal ich ebenso wie Deathguardian auch so eine Wollmilchsau vor mir habe. Da arbeite ich zwar im Großen und Ganzen alleine dran - aber es kommen aus diversen Ecken Änderungsanforderungen und es wird sehr schwer bis nahezu unmöglich diese gekapselt zu transportieren. Hätte ich vor Urzeiten schon die von 1-1-Version eingesetzt, wäre das jetzt doch einfacher.

Praktisch hingegen setze ich es (noch) nicht so ein.
1.) Wenn von 2 verschiedenen Stellen her neue Unterroutinen angelegt werden, müssen im Rahmenprogramm auch 2 neue Includes eingebaut werden. Damit sperrt dann doch wieder die 1. Entwicklung die 2 oder man muss jeweils sofort nach Anlage einer (dann noch leeren) Form das Rahmenprogramm sofort transportieren. Und ich kenne durchaus die eine oder andere Firma wo ein Transportauftrag scheinbar Unmengen an Gold kostet - so schwer ist es durchzusetzen, dass man mehr als einen TA für seine Aufgabe benötigt.

2.) Ich persönlich verwende durchaus lange Namen für Formroutinen und Programmnamen (auch wenn ich dafür schon mehrere Lynchandrohungen bekommen habe ), die die maximale Länge ausreizen. Da stößt die automatische namensgenerierung an ihre Grenzen.


Nichtsdestotrotz halte ich die SAP-Vorgehensweise mit den kleinen Includes grundsätzlich für den richtigen Weg. Muss mich selber halt dazu zwingen es auch einzuhalten.
Aber wie bei sehr vielen Sachen in der Programmierung sollte sowas nicht iin Stein gemeißelt sein. Ich verwende auch andere Ansätze der Partitionierung des Quellcodes, wenn ich der Meinung bin, dass dies die Lesbarkeit des Codes steigert. ( Zusammenfassung thematisch zusammengehöriger Programmteile in Includes wäre ein möglicher Ansatz )
Und grad bei kleinen bis mittleren Programmgrößen halte ich einen Sourcecode ohne Includes für viel einfacher lesbar.

black_adept hat geschrieben:Nichtsdestotrotz halte ich die SAP-Vorgehensweise mit den kleinen Includes grundsätzlich für den richtigen Weg.

Die Frage ist, ob man es nicht übertreibt, wenn man für jede einzelne Werthilfe eines jeden einzelnen Dynprofeldes ein Include programmiert (weil man es sinnvollerweise in eine FORM packt, sonst hat man die Werthilfen in den Rahmenprogrammen und die Arbeit an EINER Werthilfe verhindert die gleichzeitige Arbeit an ANDEREN Werthilfen und man ist wieder beim Sperr-Problem).



Ralf

@ralf.wenzel

Modulpools sind tatsächlich veraltet, das sei auch kein besonderes Geheimnis - schon allein weil sie aufruftechnisch viel unflexibler sind als zum Beispiel eine Funktionsgruppe

Das halte ich für eine sehr gewagte Aussage, um es mal vorsichtig zu formulieren.
Technisch ist eine Funktionsgruppe nichts anderes als ein Modulpool.

was er beurteilen kann, weil er dort programmiert hat

Wo und was? Die Zeiterfassung in Bangalore ? Sorry, aber das ist in dieser Form nun wirklich eine Aussage die nicht den geringsten Wert hat.

Es ist nicht falsch und hat keine Nachteile, pro FORM ein INCLUDE anzulegen. Es produziert so gut wie keinen Overhead, keine Laufzeitprobleme

Das ist richtig, wenn man den Generierungsprozess ausser Acht lässt (was ich für ok halte). Es bleibt am Ende eine Frage der Lesbarkeit. Wie so oft liegt die Wahrheit irgendwo in der Mitte. Bei grossen Projekten fassen wir mehrere zusammenpassende Module in einem Include zusammen; in kleinen Projekten gibt es je einen TOP, I,O und F-Include.

Das Problem der Sperren zwischen mehreren Entwicklern ist nur lösbar indem man auf das SAP-Transportsystem verzichtet. Auch (oder gerade dann) wenn ein Modul in einem einzelnen Include liegt, lässt es sich unabhängig von anderen Änderungen transportieren - was im Zielsystem mal eben einen Syntax-Fehler auslösen kann.
Daher ist es geradezu erwünscht, wenn Sperren anzeigen daß man nicht alleine an dem Projekt werkelt... Das Zauberwort heisst dann Abstimmung mit den Kollegen.

Zur Ausgangsfrage: wenn Modulpools veraltet sind, ist es die gesamte Entwicklungsumgebung denn die baut im wesentlichen auf dieser Technik auf, auch da wo man es nicht sieht.

Gruss
Daniel

Daniel hat geschrieben:Wo und was? Die Zeiterfassung in Bangalore ? Sorry, aber das ist in dieser Form nun wirklich eine Aussage die nicht den geringsten Wert hat.

Ich kenne die Details, aber ich werde sicherlich nicht ohne Zustimmung von irgendjemandem Details im Internet veröffentlichen.

Daniel hat geschrieben:Daher ist es geradezu erwünscht, wenn Sperren anzeigen daß man nicht alleine an dem Projekt werkelt... Das Zauberwort heisst dann Abstimmung mit den Kollegen.

Ok, du hast ein Projekt, das ein Vierteljahr Programmierzeit in Beschlag nimmt. Nach drei/sechs/12 Wochen taucht ein Fehler im Produktivsystem auf.

Baust du den ganzen Rotz zurück um den Fehler zu beheben? Oder sagst du dem Fachbereich "Ok, bucht mal x Wochen weiter falsche Belege ins System, das Progamm ist leider durch eine Entwicklung gesperrt".

Daniel hat geschrieben:Zur Ausgangsfrage: wenn Modulpools veraltet sind, ist es die gesamte Entwicklungsumgebung denn die baut im wesentlichen auf dieser Technik auf, auch da wo man es nicht sieht.

Na, dass man die SAP Entwicklungsumgebung heute völlig anders aufbauen würde, würde man JETZT damit anfangen, es zu designen, steht außer Frage - das gilt im Übrigen für SAP an sich auch.

Die Wahl hat man aber nicht, das ist eine gewachsene Struktur. Die Frage ist doch, was man bei NEUentwicklungen macht.



Ralf