Quelle est la meilleure approche pour auditer une grande application web java/j2ee?

Question

Je dois auditer une application web Java/J2ee de grande taille qui a évolué sur plusieurs années . Il a été écrit par une autre société, pas celle pour laquelle je travaille. En c'est l'état actuel, il est devenu difficile d'évoluer et de maintenir, les nouvelles fonctionnalités sont difficiles à ajouter et conduisent souvent à des bugs qui apparaissent parfois dans la production . Il semble y avoir du code copié/collé qui a entraîné la duplication de code. L'application actuelle est une sorte de magasinage en ligne avec du contenu de type cms ici et là. Il s'agit principalement de Struts et du ressort dans les nouvelles parties du code, peut-être quelques ejbs lancées pour bonne mesure. Certains tests unitaires sont disponibles, mais pas beaucoup. Ce sont des choses qu'on m'a dites, je n'ai pas encore vu le code réel.

Mon entreprise fera une proposition pour réécrire des parties de cette application afin de réduire la complexité, améliorer la qualité et la modularité, et permettre d'ajouter nouvelles fonctionnalités sans régressions. Avant de faire un engagement, ils aimeraient avoir une sorte d'appréciation de la qualité du code existant et d'évaluer combien de celui-ci peut être réutilisé, afin d'avoir plus qu'une estimation de ce qu'il doit y avoir done - réécriture complète ou partielle réécriture. Le hic, c'est que je vais devoir le faire dans une très courte période (quelques jours), donc je suis essayant de trouver un plan pour ce qui peut être fait en si peu de temps. Ce que je suis thiking est:

• vérifier les choses « de base » - traitement des exceptions, l'exploitation forestière
• vérifier le niveau de superposition (vues, contrôleurs, couche dao)
• mesurer la couverture réelle de la tests unitaires
• courent peut-être un peu Checkstyle, Findbugs et PMD sur les projets
• ...

la question réelle est ce que d'autres choses sh ould je prends en compte/check/measure/etc?

Je ne sais pas quel genre de chiffres que je pouvais sortir de cette situation et si cela signifie vraiment quelque chose, j'ai le sentiment que ce que la direction demande est en quelque sorte l'approche mal, donc la deuxième question serait: quelqu'un a-t-il une meilleure idée?

J'apprécierai toute idée, suggestion, commentaire à ce sujet.

Edit: Je vais ajouter deux détecteurs de code mort au mélange: UCD et DCD

Answer 1

J'ai eu deux applications Web avec des paramètres similaires à vous. J'ai arrêté d'utiliser FindBugs et Checkstyle car ils montraient plus de 10.000 points problématiques. Les applications utilisaient l'accès aux données de niveau JDBC, JSP pour la présentation et un cadre personnalisé pour l'envoi des demandes. Heureusement pour moi, ces paramètres de bas niveau m'ont permis de faire les extensions et les correctifs en difficulté moyenne. Pendant le projet de 3 ans, seulement environ 20% du code original est resté comme il était. Tôt ou tard, tout le reste devait être changé, remplacé ou retiré (et finalement j'ai pu utiliser FindBugs et Checkstyle).

Nous avons également fait face au dilemme de la réécriture complète. Cependant, il y avait plusieurs facteurs contre:

• Vous n'êtes pas sûr que le client paiera pour une réécriture complète.
• Le manque de documentation fonctionnelle et technique rend la réécriture complète risquée. Manhours pour comprendre pleinement l'application complète était trop élevé. Le client voulait les changements demandés plus tôt.
• Les utilisateurs ont été personnalisés pour la présentation et le comportement de la page. Il semblait difficile de convaincre les utilisateurs d'utiliser une nouvelle interface pour les anciennes fonctions.
• Si nous procédons à une réécriture complète, nous devons fournir une documentation complète. Pour la mise à jour, nous devions documenter seulement notre partie.
• Il est difficile de convaincre la direction (propre et le client) d'une réécriture si le programme fonctionne (plus ou moins)
• La société avait ses propres règles PMD et le code n'a pas passé. Il était plus simple de soutenir qu'il suffit que les nouvelles pièces passent le test.

Il résume ce que vous voulez faire réellement.

Voulez-vous réécrire, malgré la complexité?

• Mettre l'accent sur les bogues de code. Les grands camemberts avec beaucoup de rouge sont convaincants. Expliquer les propriétés du programme et comment elles ne correspondent pas à la vision de l'entreprise.
• Afficher les options d'amélioration au-delà des exigences actuelles et décrire comment la version actuelle n'est pas à la hauteur du défi.
• Faire des entrevues avec les vrais utilisateurs. Ils pourraient signaler des problèmes importants avec la version actuelle.
• Soyez bon marché mais un bon estimateur. Vous pourriez retarder certains coûts jusqu'à la phase de maintenance.

Vous ne voulez pas réécrire?

• Mettre l'accent sur le coût, en particulier les manhours requis du client pour tout tester à nouveau.
• Soulignez le problème potentiel de la fonctionnalité de rupture.
• Demandez un rédacteur de document à temps plein.

Si vous voulez goûter le code, essayez d'ajouter le Hello World! fonction/écran à l'application. Cela indique combien dur et à quelle vitesse vous pouvez mettre en œuvre de nouvelles choses.

Answer 2

J'aime votre liste beaucoup. Je pense que vous avez un excellent plan d'attaque pour commencer.

Je regarderais avec un oeil à la normalisation sur Spring ou EJB 3.0 mais pas les deux.

Je ne l'ai pas lu moi-même, mais je me demande si le livre de Michael Feathers "Working Effectively With Legacy Code" a de bonnes idées?

MISE À JOUR:

Peut-être que vous pouvez aider les choses en les mettant sur une construction automatisée et intégration continue - Régulateur de vitesse, Hudson, ou équipe de la ville. Si vous devez faire un refactoring, cela vous aidera.

Answer 3

Vous vous concentrez sur la maintenabilité et l'extensibilité.

J'ajouterais en regardant combien de temps cela va prendre pour redémarrer le projet. Utilisent-ils le contrôle de la source? Ont-ils des environnements séparés pour l'intégration et les tests d'acceptation des utilisateurs? Y a-t-il un serveur de build?

Lorsque vous devez passer deux mois avant l'apparition de la première amélioration, quelqu'un doit gérer les attentes du client dès le départ.

Answer 4

En fait, ils ne paierons pas pour une réécriture complète, parce que:

• Il est la récession, le coût de vous réécrire à partir de zéro sera élevé

• Ils pourraient essayer de vendre la société dès que possible

• la direction ne comprend rien au sujet du développement de logiciels

Je voudrais tout d'abord aller avec quelques faits simples:

• Utilisez un outil pour afficher le SLOC du projet
• Exécuter en tant que vous avez prévu FindBugs et éventuellement PMD, pour estimer les défauts
• Faites un profilage rapide Session
• Vérifiez les différentes couches
• Voir si les ressources sont généralement fermées (cours d'eau, les connexions Hibernate ou JDBC, etc.)
• Voir si les technologies sont utilisées là où elles ne sont pas applicables (EJB, Web services, etc.)
• voir comment ils gérer les exceptions et l'exploitation forestière
• Voir s'il y a trop abstraction beaucoup ou pas assez
• Voyez si vous pouvez ajouter quelques classes de base pour réduire la duplication de code

Essayez de dessiner un diagramme rapide l'architecture de l'application, si elle ne vous donne pas un document à ce sujet. Rassemblez quelques statistiques et quelques faits, rédigez un rapport et envoyez-les à l'entreprise. Ils voudront minimiser les coûts et vous demanderont d'éviter de corriger le code qui n'est pas cassé. Vous commencez avec les statistiques, puis les faits et une proposition avec le temps/pourcentage approximatif de code affecté/prix.

Habituellement, les applications héritées de Struts sont un pita à maintenir, cela a été fait. Si cela ne faisait pas partie de votre travail, je dirais qu'il faut laisser tomber. Si vous rencontrez des pages "autonomes" qui n'impliquent pas beaucoup de modèles et qui sont sujettes à de nombreux changements, proposez-leur de les réécrire avec d'autres technologies.