[Gelöst]:Refactoring einer Branchenlösung

Hallo zusammen,

zu meinen Aufgaben gehört es eine Branchenlösung zu betreuen, die auch in das Finanzmanagement und den Verkauf eingreift. Diese Lösung ist mit der Vorgängerlösung weit über 10 Jahre alt. Aber aufgrund von gesetzlichen Anforderungen immer wieder weiterentwickelt worden. Ursprünglich war ich nicht dabei, habe die Entwicklung nur am Rande mitbekommen. Selbst erfahren habe ich sie nun seit etwas mehr als 1,5 Jahren. Einige der anfänglichen Entwickler sind schon aus dem Team ausgeschieden. Damit ergeben sich nun klassische Probleme des gewachsenen Codes. Die Lösung läuft sehr stabil, allerdings ist im Code kaum dokumentiert und die Programmierstile unterscheiden sich von Funktion zu Funktion. Außerdem ist die schriftliche, technische Dokumentation weitestgehend ausgeblieben. Daher frage ich mich ob es Sinn machen würde ein grundsätzliches Refactoring für die Lösung durchzuziehen. Habt ihr mit sowas Erfahrungen gehabt? Kann man das irgendwie abschätzen und planen? Es würde sich nicht nur darauf beschränken die Variablen nach Guideline umzubenennen. Leider müsste man teilweise Code aus Funktionen oder Objekten rausnehmen und umziehen, der an dieser Stelle nicht mehr passend erscheint. Ich befürchte, dass wir aufgrund dieser Umstände in Teufels Küche kommen werden .

Viele Grüße
Koni

Zuletzt geändert von Koni am 19. September 2017 15:01, insgesamt 1-mal geändert.

Hallo,

welche NAV- Version ist den Basis für das ganze?. Prinzipiell kann man auch noch von der ältesten NAV Version auf 2017 aktualisieren (auch Forms in Pages), Es ist nur eine Frage des Aufwands, und der geeigneten Tools.

Die erste Frage ist: Was wurde angepasst? Das findet man eigentlich sehr schnell mit einem Mergetool heraus, wenn man einen Textexport machen kann.
Dann muss man sich fragen, sind diese Anpassungen heute im Standard enthalten? Falls ja, kann man es benutzen, und kann/muss ich die Daten dann konvertieren?

Eine weitere Frage, die geklärt werden muss, ist: Kann man das Update überhaupt durchführen. Es gibt ein paar Addons in alten Versionen, die ein Update erschweren (z.B. Impuls- Lagerregulierung in NAV 2.XX).
Ist das Zeitfenster für ein Update so groß und der Datenbestand so klein, dass man alle Updateschritte nacheinander (2.X->4.x->2009->2013->-2017) fahren kann, oder muss man die Update-Schritte so anpassen, das man auf de CC- Seite nur einen und auf der RTC-Seite auch nur einen Update- Schritt hat, den man durch SQL-Skript(e) unterstützt.

Wenn du das alles geklärt hast, du zu einer Zeitschätzung gekommen bist, und der Kunde nicht tot vom Stuhl fällt, wenn du ihm die Kosten erzählst. Dann viel Spaß

Gruß Fiddi

Hallo,

ich glaube du bist noch nicht in der Sache genau drin. Mit Refactoring ist nicht die Migration eines bestehenden alten Systems auf die neue Version 2017 gemeint. Sondern die Änderung von Quellcode mit dem Ziel ihn lesbarer zu bekommen, in Funktionen zu zerlegen und im Quellcode selbst sowie im Document Header entsprechende Vermerke zu hinterlegen. So stelle ich mir zumindest meine Absicht vor. Vielleicht hast du schon mal von Spaghetticode gehört? Also Code, der auf Anhieb nicht mehr verständlich ist. So geht es mir teilweise, obwohl es so schlimm nun auch wieder nicht ist. Ich müsste übrigens nur in der aktuellen Version für 2017 eine Überarbeitung vornehmen, da unsere Kunden schon weit fortgeschritten sind.

Der Code, so wie er jetzt da steht würde sich teilweise also ändern. Die Semantik, sprich die komplette Logik, muss natürlich genau so funktionieren wie auch jetzt schon. Das scheint mir das Schwierige und Quelle für viele Fehler zu sein. Wenn im Nachhinein nicht das raus kommt, was jetzt passiert, wäre die ganze Arbeit umsonst.

Wenn ihr zu einer derartigen Problemstellung noch nichts sagen könnt, dann muss ich wirklich mal schauen.

Das scheint mir das Schwierige und Quelle für viele Fehler zu sein. Wenn im Nachhinein nicht das raus kommt, was jetzt passiert, wäre die ganze Arbeit umsonst.

Das zeigt auch Erfahrung: die Änderungen / Neuprogrammierungen sind nicht immer nur Verbesserungen/Fehlerbehebungen sondern ab und zu auch neue Bug's, die natürlich nicht beabsichtigt waren, aber jeder macht halt Fehler. Die Arbeit wäre nicht nur umsonst, sie hätte u. U. auch wirtschaftlichen Schaden für die Firma eingerichtet, wenn Teile der Lösung oder diese ganz nicht funktionieren würden. Wenn die derzeitige Lösung voll von Bug's wäre, wäre Refactoring evtl. gerechtfertigt. Aber wenn diese trotz Spagetti-Code sehr stabil läuft, würde ich vom Refactoring abraten. Nur aus purer Lust den Programmcode verständlicher/strukturierter zu gestalten? Nach dem Refactoring müssen ja alle direkt oder indirekt betroffenen Prozesse in der Lösung von den Anwendern ausgiebig getestet werden, diese Prozesse müssen ja identifiziert werden usw. Ich würde mich nur auf Pflege der bestehenden Lösung im aktuellen Zustand konzentrieren (Fehlerbehebungen, Performanceoptimierungen usw. --> wenn diese solche Probleme auftauchen), und nicht mehr.

Hallo,

ich denke schon, das ich weiß was Spagetticode ist. Ich habe mein erstes Kassenprogramm auf einem C64 vor etwa 35 Jahren geschrieben. Und glaube mir es, ist mir schon einiges an Code untergekommen (dabei war auch eine TurboPascal- Logik- Simulation, die mit einigen Tausend Zeilen, die aber nur aus der Main- Prozedur und diversen Goto's bestand ).

Aber zurück zum Thema: Bevor du anfängst zu Programmieren oder zu dokumentieren, solltest du erst einmal herausfinden was du überhaupt bearbeiten musst.
Für mich ist dazu zunächst eine Analyse der Felder und des Quellcodes wichtig, die herausfindet, was angepasst wurde, und auch ganz wichtig: Was davon auch noch benutzt wird.
Alte Tabellenleichen aus MwSt.- bzw. Euro- Umstellung, oder alte Sicherungskopien von NAV- Updates oder Daten- Korrekturen gehören zu dem ersten, was ich aus einem Objektstand entferne, den ich migrieren oder analysieren will. Der nächste Schritt ist es, herauszufinden, welche anderen Objekte Leichen sind, immer wieder gerne genommen werden Einmal-Reports für Korrekturen und Sicherungskopien von "wichtigen" Reports bevor etwas geändert wird.
Nachdem man nun einen Großteil des Quellcodes entsorgt hat , ist mein nächster Schritt, herauszufinden welche Felder in der Datenbank zusätzlich enthalten sind, welche vorhandenen geändert wurden, und welche überhaupt benutzt werden. Welche Felder neu oder geändert sind, kann man relativ leicht mit Excel erledigen und einem Comparetool erledigen. Für das ob und wo verwendet, benötigt ein Crossrefference- Tool (z.B. Object Manager Advanced, GDT Where Used,Statical Prism,...)
Wenn man nun weiß, was geändert wurde, kann man prüfen ob und wie man das noch braucht, und ob und wie man das in welcher Form nach einem Update weiter verwenden will, kann oder muss.
Sind alle überflüssigen Felder entfernt, folgt ein Compile-All, der den zu den entfernten Feldern gehörenden Code aufdeckt. Nachdem man auch diesen Code und die dabei überflüssig werdenden Objekte entsorgt hat, hat man hoffentlich so etwas wie eine saubere Version, mit der man weiter arbeiten kann.
Den Quellcode dieser Version kann man mit einer sauberen NAV- Version vergleichen auf der deine angepasste Version basiert (also z.B. den eigenen Objektstand basierend auf NAV 4.0 mit einer CRONUS NAV4.0- Demo-DB vergleichen), und erhällst die relevanten Anpassungen, die du dann dokumentieren, anpassen und evtl. auch in eine neue NAV- Version übernehmen kannst.

@Jupiter:
Auf den erste Blick hast du recht. Auf den zweiten Blick holt dich diese Taktik irgendwann ein. "Never change a running System" funktioniert, wenn man auf absehbare Zeit nichts daran machen musst. Aber das ist bei NAV nicht so. Es gibt laufend neue gesetzliche Anforderungen, oder MS meint, dass die alte NAV-4.0 Version auf einem neuen Windows 11 nicht mehr funktioniert. Dann bist du gezwungen ein Update zu machen. Und glaube mir, jede Leiche die du dann im Keller hast, feiert ihre Wiederauferstehung, und ärgert dich.

Gruß Fiddi