Strategie für Komponentenumbau

[PatkIllA]

Ich bin gerade dabei eine recht wichtige Komponente neuzuentwickeln. Der Umfang liegt bei einer niedrigen fünfstelligen Anzahl Zeilen. Für die Übergangszeit (ein paar Monate bis zur neuen Version) sollen beide Komponenten parallel laufen.

Ich würde sagen, dass gut die Hälfte komplett neu wird. Das Problem ist jetzt die andere Hälfte. Der Code braucht wahrscheinlich an vielen Stellen ein paar minimale Änderugen und gleichzeitig wollte ich den bei der Gelegenheit noch mal reviewen bevor der übernommen wird.

Mir fällt irgendwie nichts besseres ein, als den Code Stück für Stück zu kopieren und die kleinen Anpassungen zu machen. Code kopieren ist ja eigentlich ein Nogo und mergen kann ich dann auch nichts mehr.

[Monger]

Nur um es nochmal explizit auszusprechen: was genau ist deine Frage? Was macht dir Sorgen? Warum solltest du den Code neu mergen müssen wenn die alte Komponente unverändert bleibt?

[PatkIllA]

Wenn in der alten Komponente doch noch Fehler sind oder noch eine Funktion hinzukommt müsste das ja auch in die neue. Kann ich nicht ausschließen, auch wenn es wahrscheinlich nur Kleinigkeiten sind.

Code kopieren macht mir halt Sorgen.

[Monger]

Wenn ich das so lese, kriege ich Kopf- und Bauchschmerzen. 50.000 LOCs für eine einzelne Komponente sind ne ganze Menge. Sitzt du da alleine dran, oder ist an der Neuentwicklung da jetzt ein Team dran?

Lass mich raten: keine Tests? Oder wie hoch ist die funktionale Deckung? Was mich auch stutzig macht, ist dass 50% des Codes erhalten bleiben. Lässt sich die Komponente nicht stärker aufbrechen? Und vermutlich keine konfigurierbare Komposition?

Mal aus der Theorie heraus gesprochen, idealerweise sollte es so laufen:
Eine Komponente lässt sich jederzeit gegen eine andere Komponente austauschen, solange sichergestellt ist dass beide das selbe Verhalten zeigen. Sofern du die öffentliche API mit ausreichend Tests gesichert hast, kannst du die selben Tests gegen die neue Komponente laufen lassen, und sicher sein dass sie sich genau verhält.
Idealerweise ist der Code soweit entkoppelt, dass sobald die Tests mit grün laufen du nur an einer Stelle anschließend was ändern musst um Komponente A durch B im gesamten Produkt zu ersetzen. In deinem Fall ersetzt man halt idealerweise nur die Neuimplementierungen die man braucht, und lässt den restlichen Code stehen.

Aber ich vermute mal, das ist von deiner Realität sehr weit entfernt. Wie sieht es denn aus? Irgendeine Chance diesen großen Klotz in Unterkomponenten aufzubrechen? Wie sieht es mit Tests aus?

[5tyle]

Was wäre die Alternative dazu, den Code nach und nach zu kopieren? Bzw. anders herum gefragt, bringt das so große Nachteile mit sich? Wenn eine komplette Neuentwicklung nicht in Frage kommt, wie soll mans sonst machen?
Schwer zu sagen wenn man auch den Grund für die Neuentwicklung nicht kennt, ist die Komponente technisch veraltet, hat sie besondere Fehler oder andere Gründe... Auch nicht ganz klar ist wie eng die Komponenten gebunden sind.

[Godmode]

Wenn es keine Tests gibt, würde ich jetzt damit anfangen. Das bietet sich jetzt ja gerade zu an. Wenn es Tests gibt, dann sollte das alles kein all zu großes Problem sein, oder?

[PatkIllA]

Ich würde eher im Bereich knapp 20000 LOC schätzen. Das meiste ist meine Baustelle.
Tests gibt es für das meiste. Ein großer Teil ist direkt mit Tests bei der Entwicklung entstanden.

Die öffentliche API bleibt zum Teil erhalten, aber eben auch nicht komplett. Dementsprechend muss auch der Teil der nutzende Module nach und nach angepasst werden.
Es ist also nicht so, dass nur die Komponente gegen andere mit gleicher API ausgetauscht wird.

Wirklich aufbrechen kann man das auch nur bedingt, da dass eng zusammengehört und auch aus Nutzersicht will man da nicht mit verschiedenen Komponenten hantieren will.

Grund für die Umstellung ist, dass die derzeitige Variante nicht mehr die gestiegenen Anforderungen erfüllt und dementsprechend von diversen Leuten an diversen Stellen herumprogrammiert werden musste.

[hadez16]

Es hängt ja auch stark davon ab was geändert wird in Verbindung mit der Übernahme von altem Code.

Wenn du z.B. operatoren nun anders überschreibst dann stelle ich mir den Review des zu übernehmenden Codes sehr viel anspruchsvoller vor wie wenn du an Parameterlisten schraubst und dir der Compiler dann sagt ob du noch irgendwo was übersehen hast.

Wie schon gesagt, Testcases / UnitTests mit entsprechender CodeCoverage wären hilfreich...aber wir wissen ja alle wie das so ist :freak:

[Monger]

Wirklich aufbrechen kann man das auch nur bedingt, da dass eng zusammengehört und auch aus Nutzersicht will man da nicht mit verschiedenen Komponenten hantieren will.
Ich meine jetzt nicht aus Anwendersicht, sondern aus Architektursicht. Dass der Anwender eine überschaubare API haben will ist ja klar, aber man kann ja intern trotzdem lose Kopplungen erreichen. Und dass 20.000 LOC alle zusammen nur "einem" Zweck folgen, kann ich mir beim besten Willen nicht vorstellen. Du sagst ja selber, dass bestimmte Teile der API eben bestehen bleiben, und manche nicht. Das spricht ja dafür dass hier eigentlich mehrere unterschiedliche Aspekte zusammengeschnürt sind.

Nur um besser zu verstehen wo ich ansetzen kann:
hast du schonmal was von Inversion of Control (http://de.wikipedia.org/wiki/Inversion_of_Control), oder anderen Anwendungskompositionsmustern gehört?

Für Legacy Code ist die Empfehlung: eine ausreichende Menge an funktionalen Integrationstests schreiben (Unit Tests gehen halt aufgrund starrer innerer Abhängigkeiten oft nicht), die Tests so weit abstrahieren dass man sie für beide APIs laufen lassen kann, zusätzlich Tests für all das schreiben was halt Alt- und Neuwelt unterschiedlich machen, und dann vorsichtig die Implementierung in Komponente B übernehmen bis alle Tests auf beiden Seiten grün sind.

[del_4901]

Wenn du dir nicht sicher bist, wie es am Ende aussehen soll dann kann ich Dir nur ans Herz legen einfach solange zu refactorn bis es sich gut anfuehlt. Dann musst du evtl. auch nicht mehr alles neu schreiben. Und der geleistette Testauffwand laesst aich auch mit in den neuen Code nehmen.

[PatkIllA]

Wir werden wohl die Übergangsphase ausfallen lassen. Dann kann ich auch einfach refactorn und wir müssen halt eine Woche Kraftakt zum umstellen nehmen.

Parallel kann man auch schon mal anfangen die jetzt schon obsoleten Dinge zu ersetzen.
Und die Dinge rauszuwerfen, die gar nicht erst passieren sollten. Wenn man seine Klassen und API nicht komplett dicht macht wird das sofort für Dinge missbraucht, die vielleicht ein Problem irgendwie lösen, aber in anderen Teilen nicht funktionieren und massiven Wartungsaufwand haben.

[del_4901]

Wegwerfen vllt. aber neue Dinge entwickeln und refactorn gleichzeitig ist keine gute Idee.