2009-03-09 3 views
1

Wir haben eine Legacy-App zur Unterstützung. Es ist reine JSP, d. H. JSP öffnet Verbindungen, führt Geschäftslogik durch, übermittelt Formulare (normalerweise an dieselbe JSP) und so weiter. Es ist 400+ Seiten, mit einigen Seiten sind so groß wie 100K.Jeder schnelle Weg, um eine Scriptlet-infizierte JSP-App in Struts zu konvertieren?

Es wird erwartet, dass die App in den nächsten Jahren erweitert und modifiziert wird. Daher suchen wir nach Möglichkeiten, die Präsentations- und Geschäftslogik zu trennen, um die Wartung zu vereinfachen. Zumindest möchten wir es in ein einfaches MVC-Framework portieren (Struts ist # 1 Kandidat).

Niemand ist begeistert, jede Seite manuell zu refaktorieren. Wir hatten eine Idee, dass es irgendwo ein Werkzeug gibt, das zumindest das partielle Refactoring durchführt, z. erstellt ActionForm basierend auf request.getParameter() -Aufrufen in JSP, verschiebt den gesamten Java-Code in Aktion (obwohl nicht kompilierbar), ersetzt einige "<% if" durch < c: if-Tags und so weiter.

Die verbleibende Arbeit ist immer noch sehr langweilig, aber zumindest hat es einen viel kleineren Umfang.

Kennt jemand solch ein Werkzeug?

+0

Ich denke, dass Sie einige Skripts schreiben müssen, um zu tun, was Sie wollen. Perl wird hier wahrscheinlich ein guter Freund sein. – sfossen

+0

Ich bin völlig bereit dazu. Wenn ich nachdenke, kann es sein, dass eine arme Seele es vor mir getan hat, und Google ist sich dessen nicht bewusst. –

Antwort

4

Ich denke nicht, dass es es wert ist. Sie sagen, Sie haben 400+ Seiten mit einigen über 100k?

100k !!!

Wahrscheinlich ist der beste Ansatz, eine gute Analyse auf dieser Webanwendung zu nehmen und sie zu modularisieren. Sie können völlig neue Module in anderen Frameworks geschrieben haben und immer noch in Verbindung verwendet werden.

Für die Seiten, die 100K sind, sind sie gute Kandidaten ihrer eigenen Module.

Ich sehe keinen Vorteil darin, einfach das ganze JSP-Chaos in ein anderes Framework-Chaos zu übersetzen. Was passieren wird ist, dass es einfach in Stücke zerbricht und niemand wird das Gefühl haben sie zu reparieren.

Der gute Teil ist? Welche Module werden zuerst gehen? Was sollte sich nicht ändern?

Ich würde mit denen beginnen, die in den letzten Monaten mehr Änderungen hatten. Die Tatsache, dass eine Datei 100K ist, bedeutet nur, dass neue Features hinzugefügt werden müssen, aber das Modell war so schlecht entworfen, dass man, anstatt neue Objekte zu erstellen, Code einfach kopieren/einfügen und mit einem if versehen würde (ich fühle mich fast wie ich) habe deinen Code schon gesehen) und die Datei wächst und wächst.

Einige Teile scheint leicht zu migrieren, aber die Quelle Kontrolle sagt niemand in 2 Jahren berührt haben. lassen Sie sie in Ruhe.

Mehr als mit einem schönen Rahmen. Sie sollten die am stärksten betroffenen Teile des Systems migrieren und neu schreiben und dieses Mal Testfälle erstellen.

Außerdem sollten Sie einen Projektstil erstellen und automatisch mit etwas wie checkstyle validieren, damit niemand neue schnelle Patches festlegt.

Schließlich wird nicht die gesamte Anwendung migriert, aber die neuen Änderungen werden einfacher durchzuführen und die Anwendung leichter zu warten.

+0

Ich stimme Ihnen vollkommen zu, dass ein solcher Ansatz der beste wäre, aber leider haben wir ein Budget. Und ziemlich eng.Die Automatisierung würde tatsächlich einige Hände frei machen, um genau das zu tun, was Sie vorgeschlagen haben - um die schlimmsten Teile neu zu gestalten. –

+0

Ein zusätzlicher Grund dann. Niemand möchte mehr Zeit damit verbringen, Dinge zu reparieren, die (noch) nicht kaputt sind: P Konzentriere dich auf den Kern der App und migriere sie bei Bedarf von Hand. Die Investition wird sich auszahlen. Automatisch reparieren, erstellt nur "Roboter Chaos" – OscarRyz

+0

Wenn ich nur wüsste, wo ist der Kern in diesem verdammten Chaos! :-D –

Verwandte Themen