Quelle est la meilleure façon de migrer une application Web désordonnée existante vers un MVC élégant ?[fermé]

Question

J'ai rejoint une nouvelle entreprise il y a environ un mois.L'entreprise est de taille plutôt petite et dégage un fort sentiment de « start-up ».Je travaille en tant que développeur Java dans une équipe de 3 autres personnes.La société vend principalement un service destiné aux entreprises/personnes commerciales à utiliser pour communiquer entre elles.

L'une des principales choses sur lesquelles j'ai travaillé et travaillerai est le site Web principal de l'entreprise - à partir duquel le service est vendu, les utilisateurs existants se connectent pour vérifier leur service et payer leurs factures, les nouveaux utilisateurs peuvent s'inscrire pour un essai. , etc.Il s'agit actuellement d'une application JSP déployée sur Tomcat, avec accès à une base de données via une couche de persistance écrite par l'entreprise elle-même.

Une frustration répétée et croissante que j'éprouve ici (et je suis plutôt satisfait du travail dans son ensemble, donc ce n'est pas un message de type "oh non, je n'aime pas mon travail") est l'absence de conception plus large ou architecture pour cette application Web.L'application est composée de plusieurs dizaines de pages JSP, avec presque aucune logique existant dans les servlets, les beans ou tout autre type de framework.La plupart des pages JSP sont constituées de milliers de lignes de code. jsp:include d'autres pages JSP, la logique métier est mélangée au HTML, les extraits de code fréquemment utilisés (comme l'obtention d'une connexion à un service Web) sont coupés-collés plutôt que réutilisés, etc.En d’autres termes, l’application est un véritable désastre.

Il y a eu quelques rumeurs au sein de l'entreprise concernant la tentative de réarchitecture de ce site afin qu'il s'adapte mieux à MVC ;Je pense que les développeurs et les supérieurs commencent à se rendre compte que ce modèle actuel de code spaghetti n'est pas durable ni très facilement évolutif pour ajouter plus de fonctionnalités aux utilisateurs.Les supérieurs hiérarchiques et les développeurs hésitent à réécrire complètement le système (avec raison, car cela signifierait plusieurs semaines ou mois de travail pour réécrire les fonctionnalités existantes), mais nous avons eu quelques discussions sur la réécriture (lentement) de la chose. écrire certaines zones du site dans un nouveau cadre.

Quelles sont les meilleures stratégies pour permettre de faire évoluer l'application et la base de code dans cette direction ?Comment puis-je, en tant que développeur, vraiment aider à faire avancer les choses, et rapidement, sans avoir l'air d'un nouveau type imbécile qui arrive dans un emploi et dit à tout le monde que ce qu'il a écrit est de la merde ?Y a-t-il des stratégies ou des expériences éprouvées que vous avez utilisées dans votre propre expérience professionnelle lorsque vous avez rencontré ce genre de chose ?

Answer 1

Votre meilleur pari est probablement de le refactoriser lentement au fur et à mesure.Peu d’entre nous disposent des ressources nécessaires pour repartir de zéro avec quelque chose qui contient autant de règles métier.La direction déteste vraiment que vous passiez des mois à développer une application contenant plus de bugs que celle que vous avez remplacée.

Si vous avez la possibilité de créer des applications distinctes à partir de zéro, utilisez toutes les meilleures pratiques qui s'y trouvent et utilisez-les pour démontrer leur efficacité.Lorsque vous le pouvez, intégrez progressivement ces idées dans l’ancienne application.

Answer 2

Procurez-vous d'abord un exemplaire de Working Efficacement avec le code hérité.Identifiez ensuite la meilleure façon de tester le code existant.Le pire des cas est que vous êtes coincé avec seulement quelques tests de régression de haut niveau (ou rien du tout) et si vous avez de la chance, il y aura des tests unitaires.Il s’agit ensuite d’une refactorisation lente et régulière, espérons-le, tout en ajoutant de nouvelles fonctionnalités commerciales en même temps.

Answer 3

D'après mon expérience, «l'élégance» d'une application a généralement plus à voir avec la conception de la base de données qu'autre chose.Si tu as un super conception de base de données, y compris une interface de procédure stockée bien définie, un bon code d'application a tendance à suivre quelle que soit la plate-forme que vous utilisez.Si tu as pauvre conception de base de données, quelle que soit la plate-forme que vous utilisez, vous aurez beaucoup de mal à créer un code d'application élégant, car vous compenserez constamment la base de données.

Bien sûr, il y a beaucoup d'espace entre super et pauvre, mais mon point est que si vous voulez un bon code d'application, commencez par vous assurer que votre base de données est à la hauteur.

Answer 4

Cela est plus difficile à faire dans les applications qui sont uniquement en mode maintenance, car il est difficile de convaincre la direction que la réécriture de quelque chose qui « fonctionne » déjà vaut la peine.Je commencerais par appliquer les principes de MVC à tout nouveau code sur lequel vous êtes capable de travailler (c.-à-d.déplacez la logique métier vers quelque chose qui s'apparente à un modèle, placez tout votre code de mise en page/vue au même endroit)

Au fur et à mesure que vous acquérez de l'expérience avec le nouveau code dans MVC, vous pouvez commencer à voir des opportunités de modifier subtilement le code existant afin qu'il soit également conforme.Cela peut être un processus très lent, mais si vous parvenez à montrer les avantages de cette façon de procéder, vous pourrez alors convaincre les autres et rallier toute l’équipe.

Answer 5

Je serais d'accord avec l'approche de refactorisation lente ;par exemple, prenez ce code copié-collé et extrayez-le dans le paradigme Java approprié (une classe, peut-être ?ou mieux encore, utiliser une bibliothèque existante ?).Lorsque votre code est vraiment propre et concis, mais manque encore de stratégie architecturale globale, alors vous pourrez intégrer beaucoup plus facilement les éléments dans une architecture globale.

Answer 6

La meilleure façon est d’imprimer le code, de le froisser et de le jeter.Ne recyclez même pas le papier.

Vous disposez d’une application écrite dans des JSP de plus de 1 000 lignes.Il a probablement un modèle de domaine épouvantable (s'il en a un) et ne se contente pas de MÉLANGER la présentation avec la logique métier, il le MÉLANGE et reste là et continue de remuer pendant des heures.Il n'y a aucun moyen de supprimer le code qui est merdique et de passer à une classe de contrôleur MVC tout en faisant ce qu'il faut, vous vous retrouverez simplement avec une application MVC avec un modèle de domaine anémique ou qui contient des éléments tels que des appels de base de données. dans le code du contrôleur, vous échouez toujours.

Vous pouvez essayer une nouvelle application qui fait ce qu'il faut, puis faire en sorte que les deux applications se parlent, mais c'est une nouvelle complexité en soi.De plus, vous ferez probablement la même quantité de travail que si vous partiez de zéro, mais vous aurez peut-être plus de facilité à essayer de convaincre vos patrons que c'est une meilleure approche.

Answer 7

Refactoriser de manière itérative.Recherchez également de nouvelles fonctionnalités qui peuvent être entièrement réalisées dans le nouveau framework afin de montrer la valeur du nouveau framework.

Answer 8

Ma suggestion serait de trouver les rares pages qui ne nécessitent pas d'importation d'autres JSP, ou qui ont très peu d'importations.Traitez chaque JSP importé comme une boîte noire et refactorisez ces pages autour d'elles (de manière itérative, en testant chaque modification et en vous assurant qu'elle fonctionne avant de continuer).Une fois celles-ci nettoyées, vous pouvez continuer à rechercher des pages avec de plus en plus d'importations, jusqu'à ce que vous ayez finalement refactorisé les importations.

Lors de la refactorisation, notez les parties qui tentent d'accéder aux ressources non fournies à la page et essayez de les transférer vers un contrôleur.Par exemple, tout ce qui accède à la base de données doit se trouver à l'intérieur d'un contrôleur, laissez le JSP gérer l'affichage des informations que le contrôleur lui donne via un transfert.De cette façon, vous développerez plusieurs servlets, ou des choses comme des servlets, pour chaque page.Je suggérerais d'utiliser un framework basé sur un contrôleur frontal pour cette refactorisation (par expérience personnelle, je recommande Spring et son interface Controller), de sorte que chaque contrôleur ne soit pas un servlet distinct mais soit plutôt délégué à partir d'un seul servlet mappé de manière appropriée.

Pour le contrôleur, il est préférable d'effectuer des visites de base de données d'un seul coup plutôt que de les tenter de manière fragmentaire.Les utilisateurs peuvent tolérer et tolèrent généralement le chargement d'une page, mais la sortie de la page sera beaucoup plus rapide si toutes les données de la base de données sont transmises au code de rendu plutôt que si le code de rendu est suspendu et ne donne pas de données au client pendant qu'il essaie d'en lire un autre. morceau de données de la base de données.

Je ressens votre douleur et vous souhaite bonne chance dans cette entreprise.Maintenant, quand vous devez maintenir une application qui abuse de Spring Webflow, c'est une autre histoire :)