ILE Quellen IFS vs Source Files

[dschroeder]

m.E. liegt hier das Problem!. Klingt für mich so, dass ihr immer noch one-procedure-module macht => das führt zu enger Kopplung und breiten Parameterschnittstellen (deshalb auch die vielen Copystrecken?).

D*B

Richtig. Deshalb die vielen Copy-Strecken. Jedes Serviceprogramm hat in der Regel nur eine Procedure. Aber es würde doch am Problem nichts ändern, wenn wir 100 Procedures in ein Serviceprogramm packen würden.

Unser Problem ist NICHT, dass sich die Parameterlisten von Procedures ändern. So etwas machen wir normalerweise nur mit weiteren optionalen Parametern. Wir ändern keine bestehenden Parameter ab.

Ich sehe ein Problem in der fachlichen Logik: Wenn ein Programmierer 5 Programme in einer Testumgebung ändert, um ein bestimmtes Problem zu lösen, kann es ja sein, dass der dafür mehrere Wochen braucht. Wenn inzwischen ein anderer Programmierer wegen eines ganz anderen Problems auch einiger der Programme anpassen muss, kann ich mir nicht vorstellen, dass mir Git über ein Merge hilft, das übereinander zu bekommen. Ich muss mir doch immer inhaltlich ansehen, was der andere Programmierer erreichen wollte und ob das überhaupt zu meiner Aufgabenstellung passt.

[BenderD]

Richtig. Deshalb die vielen Copy-Strecken. Jedes Serviceprogramm hat in der Regel nur eine Procedure. Aber es würde doch am Problem nichts ändern, wenn wir 100 Procedures in ein Serviceprogramm packen würden.

Unser Problem ist NICHT, dass sich die Parameterlisten von Procedures ändern. So etwas machen wir normalerweise nur mit weiteren optionalen Parametern. Wir ändern keine bestehenden Parameter ab.

Ich sehe ein Problem in der fachlichen Logik: Wenn ein Programmierer 5 Programme in einer Testumgebung ändert, um ein bestimmtes Problem zu lösen, kann es ja sein, dass der dafür mehrere Wochen braucht. Wenn inzwischen ein anderer Programmierer wegen eines ganz anderen Problems auch einiger der Programme anpassen muss, kann ich mir nicht vorstellen, dass mir Git über ein Merge hilft, das übereinander zu bekommen. Ich muss mir doch immer inhaltlich ansehen, was der andere Programmierer erreichen wollte und ob das überhaupt zu meiner Aufgabenstellung passt.

... es geht nicht darum beliebige procedures in eine compile-Einheit (= modul) zu packen. Ziel ist Parameterschnittstellen zu minimieren und Änderungshäufigkeit zu verkleinern. Ansatzpunkt dabei ist, sich in Richtung Objekt Orientierung zu bewegen.
Statt kundeLesen, kundeSchreiben, kundeXYZ, kundeZB,... => ein Modul Kunde mit allen Prozeduren, das exportiert dann alle benötigten setXXX, getXXX Prozeduren und alles, was die Anwendung von und mit Kunde machen will, alles was der internen Kommunikation dient, wird nicht exportiert.
Damit ist der größte Teil der Suchproblematik erst mal weg. Im Regel wird 1 Objekt ausgecheckt und das wars.
Hiermit kriegt man auch mehr Überblick über die Reichweite von Änderungen. Alles, was nicht exportiert wird, wirkt nicht nach außen. Statt optionale Parameter anzuhängen, gibt es einen zusätzlichen getter oder setter, oder was auch immer benötigt wird. Hier sind dann wieder nur die tangiert, die diesen verwenden.
An der merge Problematik änder das nix, die würde ich aber immer versuchen zu vermeiden. Praktisch heißt das: Das macht man nur bei Hotfixes. Ich halte es für groben Unfug, dass Tools den Eindruck erwecken, dass sie das automatisch könnten und so den Anwender zu Murks verleiten. Konkurrierende Änderung an dem gleichen Objekt, sind für mich ein Indiz für organisatorische Mängel.

D*B

PS: ich bin mir im klaren, dass man die Mängel in eurem Anwendungsdesign nicht auf kurzem Weg abstellen kann, empfehle aber, damit anzufangen.

[dschroeder]

Vielen Dank für deinen Beitrag.

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.)
Wenn ich es nochmal neu schreiben würde, würde ich eventuell auch den Weg gehen, das in einem Service-Programmobjekt zusammenzufassen.

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.

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.

[Fuerchau]

In der Objektorientierung ist das auch durchaus vergleichbar.
Eine Klasse hat Eigenschaften und Methoden. Eine Eigenschaft kann wiederum ein Objekt sein.
Hier hat sich ebenso eingebürgert, je Klasse eine Quelle.
Damit komme ich schon schnell mal auf ein paar Hundert Klassen und Dateien.
Mir sagt mal jemand, dass jede Klasse auch ein Interface haben muss, das quasi eine eigene abstrakte Klasse ist, die auch wieder in einer Quelle stecken muss.
Aber das Durchsuchen ist in Windows/Linux-Verzeichnissen durchaus effektiver als im IFS oder der DB.

Und auch bei "Alles was den Kunden angeht", so hat man da schon einen Kundenstamm (Klasse), einen Adressstamm (Klasse), Ansprechpartner (Person-Stamm) u.v.m..

Mein kleines ETL-Tool besteht alleine schon aus 150 Klassen, da Objekte das A&O sind.

[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

[Andreas_Prouza]

Wenn ich nach Details gefragt habe, wie z.B. "wo bleiben denn die Source-Beschreibungstexte?" hieß es in etwa:
- Die meisten Programmierer sind nicht auf die Texte angewiesen
- Wenn mein Gesamtprojekt so groß ist, dass ich auf die Texte nicht verzichten kann, dann ist mein Gesamtprojekt eben nicht optimal.

Diese Aussagen und noch andere waren der Grund warum ich OBI ins Leben gerufen habe.
Leider heutzutage, wenn ein Tool eine Anforderung nicht erfüllen kann, ist automatisch die Anforderung falsch, ohne jegliche Reflexion ob die Anforderung eventuell sogar eine Bereicherung für das Tool wäre.

OBI ist nicht perfekt. Jedoch können Kundenwünsche schnell und unbürokratisch übernommen werden. Ich glaube sogar es war deine Aussage über die Source-Texte, die mich dazu veranlasst haben dieses Feature zu implementieren.

Was die (IBM) Empfehlungen betrifft ...
Für mich stellt sich die Frage: Möchte/Muss ich in den nächsten Jahren neue Entwickler ins Boot holen.
Wenn ja, welche Anforderungen sind nötig und wieviele Bewerber decken diese ab?
Mit IFS, Git und Vscode habe ich eine Basis mit der sich mehr Entwickler einfangen lassen, als mit SRC-PF & Co.

Nicht nur, dass ich mit diesem Weg mehr Möglichkeiten zur Integration diverser Tools habe (z.B. CI/CD), man wird auch interessanter für Unternehmen und eine Umschulung auf IBM i wäre einfacher zu Argumentieren.


Was das GIT MERGE betrifft, wie gesagt: Du kannst es einstellen wie du es haben möchtest. So auch ...
1. Entwickler A ändert Source ABC.RPG
2. Entwickler B ändert Source ABC.RPG
3. Entwickler A Commited seine Änderung und überträgt diese ins remote Git
4. Entwickler B Commited seine Änderung und möchte ebenfalls überträgen
4.a. Entwickler B bekommt von Git die Info, dass bereits Änderungen durchgeführt wurden und diese vorher übernommen werden müssen
4.b. Entwickler B sieht dann in einer Vergleichs-Ansicht seine Änderungen und die des Entwickler A
4.c. Entwickler B entscheidet welche Änderungen übernommen werden soll bzw. kann den Code in der Vergleichs-Ansicht auch direkt noch anpassen.
4.d. Wenn Entwickler B den MERGE abgeschlossen hat, Commited er den Merge und überträgt die Änderungen ins remote Git

Im Git ist nun alles transparent, wer was geändert und zusammengeführt (Merge) hat.

Arbeiten nun Entwickler A wochenlang an einer Source, die zwischenzeitlich von Entwickler B (wegen eines Hotfix) angepasst wurde, kann Entwickler A sich jederzeit die Änderungen von Entwickler B holen und mergen.
Somit muss Entwickler A nicht bis zur finalen Fertigstellung mit dem Merge warten.

Git kann noch viel mehr. Nicht alles wird benötigt. Dadurch ist Git DAS Versionsverwaltungs-Tool und wird in sehr vielen anderen Tools unterstützt. (JIRA, VSCode, Eclipse, Azure, Slack, Teams, Kubernetes, AWS)

[Pikachu]

In welche CCSID kopiert man die CL- und RPG-Quellen aus den Quellenteildateien am besten ins IFS?

[Andreas_Prouza]

Ich speichere sie alle als UTF-8 (ccsid 1208)