Source-Management bei Kunden-Anpassungen

[AlArenal]

Mal wieder eine Situation, die langsam auf mich zurollt und wo ich die noch verbleibende Zeit nutzen möchte, mal nachzuhaken, ob wer nen schlauen Tipp hat. Und zwar konnte ich es für meine Anwendungen bisher immer vermeiden Kunden Extrawürste zu braten. Dummerweise wird sich das zukünftig nicht immer verhindern lassen, d.h. einzelne Kunden werden beliebig kleine oder große Teile der Software (je nach Wunsch und Geldbeutel) an ihre eigenen Bedürfnisse angepasst haben wollen.

Manches kann man einfach als Idee zur Weiterentwicklung in eine neue Version einfließen lassen, manches kann man intern über Parameter steuern. Aber konkret wird es in Kürze so aussehen, dass ich mir für einige Änderungen etwas anderes überlegen muss. Für eine Anwendung, die in stetiger Weiterentwicklung ist, sind Kundenanpassungen quer durch beliebige Klassen natürlich furchtbar schlecht wartbar. Nach Möglichkeit will ich nur ein Projekt, also einen Source-Tree pflegen müssen, anstatt jede Kundenversion einzeln abzuändern - das würde in einem endlosen Chaos enden.

Auf Anhieb fallen mir folgende Herangesehensweisen ein:

a) Die Anwendung bekommt beim Start übergeben um welchen Kunden es sich handelt (Konstante aus einem Interface oder einer meiner eh schon vorhandenen Klasse Configuration) und das benutze ich intern als Schalter an allen notwendigen Stellen, um entsprechend zu steuern.

b) Jede Kundenänderung ist in gewisser Weise ja ein Feature. Also lege ich für jedes Feature einen Schalter zur Konfiguration an und über eine Konfig-Datei kann dann gesteuert werden bei welchem Kunden welches Feature aktiv/inaktiv ist.

A ist etwas einfacher in der Umsetzung und man sieht im Code an den entsprechenden Stellen direkt was zu welchem Kunden gehört.

B ist etwas mehr Arbeit in der Umsetzung, dafür kann die Konfiguration für einen Kunden aber extern gelagert und dort editiert werden (natürlich nur begrenzt im Rahmen der in der installierten Version vorhandenen Features).

Vielleicht hat ja jemand ne bessere Idee, vielleicht gibts Pattern, die einem hier das Leben leichter machen können. Wenn wer ne Idee oder Erfahrung hat, wärs cool mal zu hören, wie er das lösen würde / gelöst hat.

 

[Sky]

Es gibt das FactoryPattern.

So könntest Du Klassen in Abhängigkeit von Kunden erstellen und dein Programm würde zur Laufzeit entscheiden, welche Klasse gerade gebracht wird.
Es bietet sich bei Dir wahrscheinlich an, eine abstract Class mit Kundenspezifischen Ableitungen; schematisch dargestellt:

abstract class TheGui extends JFrame {
// Methoden, einige abstract
}

class TheDefaultGui extends TheGui {
// abstracte Methoden überschreiben
}

class TheGuiForA extends TheGui {
// abstracte Methoden überschreiben
}

class TheGuiForB extends TheGui {
// abstracte Methoden überschreiben
}

class GuiFactory {
  public TheGui getTheGui( int x ) {
    if( x == 0 ) {
      return new TheGuiForA();
    } else if( x == 1 ) {
      return new TheGuiForB();
    } else {
      return new TheDefaultGui();
    }
  }
}

Das Prinzip und den Aufbau liest Du am besten mal nach: http://www.java-forum.org/de/javabuch/html/k100068.html#ixa100630

 

[Mag1c]

Hi,

und wenn du die Klassen per Reflection instanziierst, kannst du alle kundenspezifischen Klassen in eigene .jar's auslagern und jedem Kunden nur SEIN .jar mitliefern.

Gruß
Mag1c

 

[AlArenal]

Muss ich daheim mal in meinem Manning schauen. Bin ich auf Arbeit, brauche ich die Bücher, die daheim liegen. Bin ich daheim. fehlen mir die Bücher, die aufm Schreibtisch im Büro liegen..

 

[KSG9|sebastian]

zu A) je nachdem wie du das ganze lösen willst erhöht sich die Wartbarkeit von deinem Programm nicht unbedingt.
Beispiel: Neuer Kunde kommt hinzu - welche Änderungen sind notwendig

if(){

} else if
.
.
.

Sowas erleichtert das arbeiten nicht unbedingt.
Am sinnvollsten ist es IMHO die Anwendung modular zu halten und ne Pluggable-Schnittstelle zu verwenden, über die du dann neue Features einbinden/vorhandene Features rauswerfen kannst.

So hast du ein Core-System und zusätzliche Features.
Ein weiterer Vorteil ist, wenn eine neuer Kunde gerne die Anwendung von Kunde xyz haben will, dann musst du nicht im Source-Code rumpfuschen sondern kannst nur JARs kopieren.

Für die Entwicklung bietet sich ne Config-Datei an, in der du die Kunden pflegst und dementsprechend die Library lädst oder auch nicht.

 

[Bleiglanz]

nimm B

SAP machts ja auch so, das ist ein Feature! Stichwort Customizing...

würde auch sagen, dass Variante A mit den vielen Abfragen sehr fehleranfällig ist und zu "schlecht riechendem" Quellcode führt...

würde die Konfiguration dann entweder direkt vom Kunden vornehmen lassen oder (als DAU Schutz) in einer Properties-Datei mitgeben.

Es hängt eben davon ab, ob das Feature X überhaupt für einen anderen Kunden in Frage kommt, d.h. ob man das überhaupt verallgemeinern kann; wenn deine Software von der Stange kommt (du sie also nicht als Auftragsarbeit selbst geschrieben hast), dann ist sowas immer vom Geld abhängig (und wies mit der Wartung weitergeht usw.)

Mit Subversion könntest du einfach den Quelltextordner nehmen, diesen kopieren in einen neuen Ordner "Kunde1" und den ganzen Zweig dort weiterpflegen - modulo dem "Update"+"Bugfixes" Problem