Un moyen rapide de convertir une application JSP infectée par un scriptlet en Struts?

Question

Nous avons une application héritée à soutenir. C'est une JSP pure, c'est-à-dire que JSP ouvre des connexions, fait de la logique métier, soumet des formulaires (généralement à la même JSP), et ainsi de suite. Il y a plus de 400 pages, certaines pages ont une taille de 100K. L'application devrait être étendue et modifiée au cours des prochaines années. Nous cherchons donc à diviser la présentation et la logique métier afin de simplifier la maintenance. Au minimum, nous aimerions le porter dans un cadre MVC simple (Struts est candidat n ° 1).

Personne n'est enthousiaste de refactoriser chaque page manuellement. Nous avons eu une idée qui peut être quelque part il y a un outil qui fait au moins le refactoring partiel, par exemple. crée ActionForm en fonction des appels request.getParameter() dans JSP, déplace tout le code Java en Action (bien que non compilable), remplace certains "<% if" par < c: if tags, et ainsi de suite.

Le travail restant est encore très ennuyeux, mais au moins il a une portée beaucoup plus petite.

Est-ce que quelqu'un connaît un tel outil?

Answer 1

Je ne pense pas que ça vaut le coup. Vous dites que vous avez plus de 400 pages avec plus de 100k?

100k !!!

Probablement la meilleure approche est de prendre une bonne analyse sur cette webapp, et le modulariser. Vous pouvez avoir des modules totalement nouveaux écrits dans d'autres frameworks et être toujours utilisés conjointement.

Pour les pages qui sont 100K, ils sont de bons candidats de leurs propres modules.

Je ne vois vraiment aucun avantage à simplement traduire le désordre JSP entier dans un autre désordre d'armature. Ce qui va arriver, c'est que ça va simplement se briser en morceaux et que personne n'aura envie de les réparer.

La bonne partie est? Quels modules iront en premier? Quel autre ne devrait pas changer?

Je commencerais par ceux qui ont eu plus de changements au cours des derniers mois. Le fait qu'un fichier soit 100K seulement signifie que de nouvelles fonctionnalités doivent être ajoutées, mais le modèle était si mal conçu, qu'au lieu de créer de nouveaux objets, du code était simplement copié/collé et placé avec un if (j'ai presque l'impression d'avoir vu votre code déjà) et le fichier grandir et grandir.

Certaines parties semblent faciles à migrer, mais le contrôle de source indique que personne ne l'a touché depuis 2 ans. laisse les tranquille.

Plus que d'utiliser un cadre agréable. vous devez migrer et réécrire les parties les plus touchées du système, et créer des cas de test cette fois.

De même, vous devez créer un style de projet et le valider automatiquement avec quelque chose comme checkstyle, afin que personne ne commette de nouveaux patchs rapides.

Éventuellement, toutes les applications ne seront pas migrées, mais les nouvelles modifications seront plus faciles à effectuer et l'application plus facile à gérer.