Quelle est la meilleure approche pour l'audit d'une grosse application Web java / j2ee?

Question

Je dois auditer une grande application Web Java / J2ee qui a évolué au cours de plusieurs années. Il a été écrit par une autre société, pas celle pour laquelle je travaille. Dans son état actuel, il est devenu difficile d'évoluer et de maintenir, nouvelle les fonctionnalités sont difficiles à ajouter et conduisent souvent à des bugs qui apparaissent parfois dans production. Il semble y avoir du code copié / collé qui a entraîné une duplication du code. L’application actuelle est une sorte de magasinage en ligne avec du contenu semblable au cms ici et là. Il s’agit principalement de Struts et de Spring dans de nouvelles parties du code, peut-être de la création d’ejbs bonne mesure. Il existe quelques tests unitaires disponibles, mais peu d'entre eux. Ce sont des choses que l'on m'a dit, je n'ai pas encore vu le code actuel.

Mon entreprise fera une proposition pour réécrire des parties de cette application afin de réduire complexité, améliorer la qualité et la modularité, et permettre d’ajouter plus facilement nouvelles fonctionnalités sans régressions. Avant de s’engager, ils aimeraient avoir une sorte d’appréciation de la qualité du code existant et d’évaluer la quantité de code pouvant être réutilisée, afin avoir plus qu’une hypothèse sur ce qu’il faudra faire - réécriture complète ou partielle réécrire.

Le problème, c’est que je devrai le faire dans un très court laps de temps (quelques jours), donc je suis essayer d'élaborer un plan pour ce qui peut être fait en si peu de temps. Ce que je pense, c'est:

• consultez "& basic;" " choses - traitement des exceptions, journalisation
• vérifier le niveau de superposition (vues, contrôleurs, couche Dao)
• mesurez la couverture réelle des tests unitaires
• peut-être exécuter quelques Checkstyle, Findbugs et PMD sur les projets
• ...

La vraie question est donc de savoir quelles autres choses dois-je prendre en compte / vérifier / mesurer / etc?

Je ne sais pas quel genre de chiffres je pourrais obtenir et si cela signifierait vraiment Quelque chose, j'ai le sentiment que ce que la direction demande est un peu le faux la deuxième question serait: est-ce que quelqu'un a une meilleure idée?

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

Modifier: j'ajouterai deux détecteurs de code mort au mélange: UCD et DCD

Answer 1

J'avais deux applications Web avec les mêmes paramètres que vous. J'ai arrêté d'utiliser FindBugs et Checkstyle car ils montraient plus de 10 000 points problématiques. Les applications utilisaient un accès aux données de niveau JDBC, JSP pour la présentation et une structure personnalisée pour la distribution des demandes. Heureusement pour moi, ces réglages de bas niveau m'ont permis de faire les extensions et les corrections avec une difficulté moyenne. Au cours du projet de trois ans, il ne restait que 20% environ du code original. Tôt ou tard, tout le reste devait être changé, remplacé ou supprimé (et finalement, j'ai pu utiliser FindBugs et Checkstyle).

Nous aussi avons été confrontés au dilemme de la réécriture complète. Cependant, plusieurs facteurs s’y opposaient:

• Je ne suis pas sûr que le client paiera pour une réécriture complète.
• L'absence de documentation fonctionnelle et technique rend risquée la réécriture complète.
• Les heures de travail pour bien comprendre que l’application complète était trop élevée. Le client voulait les modifications demandées plus tôt.
• Les utilisateurs ont été personnalisés en fonction de la présentation et du 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 n'avions besoin de documenter que notre part.
• Il est difficile de convaincre la direction (propriétaire et du 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 été transmis. Il était plus simple de dire qu'il suffit que les nouvelles pièces passent le test.

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

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

• Mettez l'accent sur les bogues de code. De grands diagrammes à secteurs avec beaucoup de rouge sont convaincants.
• Expliquez les propriétés du programme et en quoi elles ne s'inscrivent pas dans la vision de l'entreprise.
• Afficher les options d'amélioration allant au-delà des exigences actuelles et décrire en quoi la version actuelle ne permet pas de relever le défi.
• Faites des interviews avec les vrais utilisateurs. Ils pourraient signaler des problèmes importants avec la version actuelle.
• Soyez bon marché mais bon estimateur. Vous pourriez retarder certains coûts jusqu'à la phase de maintenance.

Vous ne voulez pas réécrire?

• Mettez l'accent sur le coût, en particulier sur les heures de travail requises par le client pour tout tester à nouveau.
• Indiquez le problème potentiel de rupture de fonctionnalité.
• 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 à quel point et à quelle vitesse vous pouvez implémenter de nouvelles choses.

Answer 2

En fait, ils ne paieront pas pour une réécriture complète, car:

• C'est la récession, le coût de la réécriture à partir de zéro sera élevé

• Ils essaient peut-être de vendre la société dès que possible

• La direction ne comprend rien au développement logiciel

Je commencerais par quelques faits simples:

• Utilisez un outil pour afficher le SLOC du projet
• Exécuter comme vous l'aviez prévu avec FindBugs et éventuellement PMD, juste pour estimer les défauts
• Faites une session de profilage rapide
• Vérifiez les différentes couches
• Voir si les ressources sont généralement fermées (connexions Streams, Hibernate ou JDBC, etc.)
• Voir si les technologies sont utilisées là où elles ne s'appliquent pas (EJB, Web Services, etc.)
• Découvrez comment ils gèrent les exceptions et la journalisation
• Voir s'il y a trop ou pas assez d'abstraction
• Voyez si vous pouvez ajouter des classes de base pour réduire la duplication de code

Essayez de dessiner un diagramme rapide de l’architecture de l’application, s’ils ne vous en donnent pas le document.

Réunissez des statistiques et des 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 endommagé. Vous commencez par les statistiques, puis par les faits et une proposition avec le temps / pourcentage approximatif du code affecté / prix.

Habituellement, les anciennes applications Struts sont un pita à maintenir, cela a déjà été fait. Si cela ne faisait pas partie de votre travail, je vous dirais de laisser tomber. Si vous rencontrez & stand; autonome " les pages qui ne comportent pas beaucoup de modèles et sont sujettes à de nombreux changements, proposent de les réécrire avec une autre technologie.

Answer 3

Vous vous concentrez sur la facilité de maintenance et l’extensibilité qui sont au premier plan.

Je voudrais ajouter en regardant combien de temps il faudra pour redémarrer le projet. Utilisent-ils le contrôle de source? Ont-ils des environnements distincts 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 la première amélioration, une personne doit gérer les attentes du client dès le départ.

Answer 4

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

Je souhaiterais normaliser 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 est " ; Travailler efficacement avec le code existant " a de bonnes idées?

MISE À JOUR:

Peut-être pouvez-vous aider les choses en les plaçant sur une construction automatisée et une intégration continue - Cruise Control, Hudson ou Team City. Si vous devez effectuer une refactorisation, cela vous aidera.