ILE Quellen IFS vs Source Files

[BenderD]

Wir sind gar nicht weit auseinander bei unseren Vorstellungen, denke ich. Die Denkweise ist bei uns durchaus objektorientiert. Du würdest alle Funktionen, die etwas mit dem Kunden zu tun haben, in ein Serviceprogramm "Kunde" packen. Wir machen das, indem wir unsere einzelnen Serviceprogramme per Namenskonvention zusammenhalten. (Alles was BVS9KU* heißt, ist Kunde, alles was BVS9VE* heißt, ist Vertrag usw.)

... der entscheidende Punkt sind, dass die zusammengehörenden Prozeduren auf gemeinsamen Daten operieren und ein Gedächtnis haben (abgebildet als im Modul globale Daten) und dass man die Zugreifbarkeit von außen differenziert abbilden kann. Bei den single procedure Modulen, muss man alle gemeinsamen Daten durch alle Parameterschnittstellen durchreichen oder gar exportieren, was noch schlechter ist. Wenn jeder alles verwenden kann, sind die AUfrufhierarchien nicht kontrollierbar und die Änderung einer der Prozeduren, kann immer alle anderen Programme betreffen.

Es kommt aber immer wieder mal dazu, dass es fachlich strittig ist, in welchen Bereich ein Programm gehört. Gehört ein "getAlleVertraegeDesKunden" zum Kundenbereich oder zum Vertragsbereich? Da kann man immer streiten.
Deshalb habe ich weiterhin die Problematik, mich schnell durch eine große Anzahl von Sourcen "durchfiltern" zu müssen. Selbst wenn Routinen in mehreren großen Serviceprogrammen zusammengefasst wären, müsste ich ja auch jedes Service-Pgm öffnen und darin suchen, wenn ich eine spezielle Funktion benötige.

Das bildet man hierarchisch ab. Sprich: Verträge benutzt Vertrag und dieser wiederum benutzt unter anderem auch Kunde. Wenn Du zuhause eine Tasse brauchst, durchsuchst Du auch nicht den Kleiderschrank, es sei denn, dass was mit dem Design Deiner Wohnung nicht stimmt.

Was mich bei vielen Diskussionen immer etwas unzufrieden zurücklässt, ist die Aussage, das unsere Anwendung "zu groß" (zu komplex, falsch geschnitten) wäre.
Ich weiß nicht, ob unsere Aufgabenverteilung im Team ungewöhnlich ist: Bei uns arbeiten die IBM i Entwickler ohne große Personalfluktuation seit Jahren und Jahrzehnten an der Gesamtanwendung. Jeder Entwickler kann jeden Bereich der Anwendung verstehen und Softwareänderungen / Erweiterungen vornehmen.

Es scheint mir so, als wäre das nicht mehr "en vogue". Man wünscht sich statt eines großen Systems ein System mit vielen kleinen Bereichen, die dann nur wenige Member enthalten.
Ich bin mir aber nicht sicher, ob damit wirklich die Komplexität abnehmen würde. Letztlich müsste ich ja doch alle Bereiche kennen, wenn ich die Möglichkeit beibehalten will, dass jeder Entwickler alles können soll.

Ich schätze mal, dass wir gut 20.000 Sourcemember mit 5 Mio Zeilen Code haben. Wenn ich das auf 200 Einzelbereiche aufteilen könnte, hätte ich pro Bereich im Schnitt immer noch 100 Sourcemember. Auch da benötige ich die Beschreibungstexte der Programme. Nur die 10 stelligen Programmnamen würden mir sicherlich nicht reichen.

Das mit der Größe kann da kein Argument sein, das ist eher eine Ausrede von Marketiers, die vom richtigen Leben weit entfernt sind. Bei Java denkt man da sofort an Javadoc. Bei RPG habe ich mich zumeist mit mit generierten Objektverwendungshierarchien beholfen, da die wenigsten Kunden da überhaupt Standards folgen. Die AS/400 bietet da ja einiges an Unterstützung (DSPPGMREF etc.) und den rest macht dann SQL auf dem generierten Repository. Programmtexten habe ich da nie vertraut, da steht meist Unfug drin.

D*B