Hallo Andreas,
vielen Dank für deinen Beitrag. Ist sehr gut und strukturiert geschrieben!

Ich kann sehr viele deiner Pro IFS Punkte nachvollziehen. Genau das ist ja auch der Grund, weshalb ich mich verstärkt mit dem Thema befasse.

Allerdings klingt es bei dir so, als wäre der Verzicht auf die Source-Beschreibungstexte nur eine kleine Unschönheit. Das ist bei uns im Team definitiv nicht so. Möglicherweise liegt das an unserer Entwicklungsstrategie, die wird seit 30 Jahren betreiben.

Unsere wichtigsten Strategiepunkte sind:

  • Lieber viele kleine Programme als ein großes Programm
  • Pro Serviceprogramm (möglichst) nur eine einzige exportierte Procedure
  • Code (möglichst) nie kopieren, sondern stattdessen Programme so auslegen, dass sie an vielen Stellen wiederverwendet werden können.


Diese Punkte führen dazu, dass Programme von vielen Stellen aufgerufen werden und dass wir sehr viele, relativ kleine, Sourcemember bekommen. Ein Sourcemember hat bei uns im Durchschnitt weniger als 250 Zeilen Code. (incl. Kommentare).

Mir ist bewusst, dass es viele Unternehmen gibt, die das mit den Serviceprogrammen anders machen und die stattdessen nur sehr wenige Serviceprogramme mit vielen exportieren Procedures haben. Aber hat man da nicht das Problem, dass eine Änderung der Parameterschnittstelle einer Procedure sofort die Signatur des gesamtes Serviceprogrammes ändert und man dann sehr viele Programme neu kompilieren muss?

Die Tatsache, dass wir versuchen, Code nicht zu kopieren, sondern stattdessen Programme zu schreiben, die wir von überall nutzen können, führt natürlich zu einem etwas "monolithischen" Gesamtsystem. Das wiederum führt dazu, dass ein Entwickler sich oft mit Programmen aus unterschiedlichen Projekten befassen muss. Das heißt, man kann sich in der täglichen Arbeit nicht ausschließlich auf einige wenige Sourcen konzentrieren, sondern man muss sich oft mit Sourcen beschäftigen, die in ganz unterschiedlichen Projekten abgelegt sind. Und dabei benötige ich die Beschreibungstexte.