Zitat Zitat von dschroeder Beitrag anzeigen
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.