Nous avons une base de code Java qui s'est développée trop grande pour un seul pot monolithique (plus de 5000 classes). L'une des tâches que nous enquêtons est de savoir combien d'effort serait-il de casser ce bocal unique en composants plus petits avec des dépendances contrôlées entre elles. Cependant, il est un peu difficile de regarder un gros sac de code et d'être sûr que vous trouvez les meilleurs points de séparation sans une analyse.
Y a-t-il de bons outils pour inspecter et visualiser les dépendances d'interpackage? Compte tenu de ceux-ci, nous aurions un ensemble de points de coupe suggéré où nous pourrions commencer à séparer le code.
À titre d'exemple, dans les jours précédant Netbeans et Eclipse (et à un travail différent), nous avons utilisé ensemble JO et ensemble. Ceux-ci avaient la possibilité de faire une analyse de l'emballage statique et de dessiner le diagramme UML. Ce type de comportement serait optimal mais cette fonctionnalité seule n'est pas suffisante pour justifier le coût.
8 Réponses :
Sonarj est un bon outil pour faire cela, mais c'est cher.
Un autre très bon outil est xdepend , qui est moins cher. Pour votre but, je vous recommanderais cet outil. Le meilleur choix en termes de qualité / prix que je pense.
Avec beaucoup moins de fonctionnalités, vous pouvez utiliser un analyse SONAR (libre et openSource) et sa matrice de dépendances.
Les classes utilisent-elles des packages de manière normale ou toutes les classes sont-elles dans le même paquet? Si le premier cas est vrai, je envisagerais d'écrire un outil spécial pour faire la première coupe.
L'architecture d'origine a jeté des choses de manière raisonnable. Toutefois, des années de demandes de clients et de nouveaux développements ont conduit à des années d'édition et il est temps de faire face à tout ce qui reviens. 5000 classes dans un paquet seraient brutes, n'est-ce pas?
@Bob Cross - Oui en effet. Je pense que je devrais jouer avec elle pendant un moment de déterminer même comment procéder.
J'ai utilisé Stan4J dans le même but, mais malheureusement, l'édition communautaire a une 500 classes limite. De l'autre côté, cela fonctionne comme une extension Eclipse.
J'ai récemment découvert CodePro Analytix, anciennement à partir d'instanciations, maintenant disponible gratuitement de Google: https://developers.google.com/java-dev -Tools / CodePro / Doc / Caractéristiques / Dépendances / Dépendances
JDePend est un outil gratuit d'analyse des dépendances du package.
Il identifie des dépendances circulaires, qui empêcherait de briser ce monolithe en pièces plus petites.
Nous mettons ce chèque pour les dépendances circulaires dans nos tests d'unité, pour les empêcher de commencer.
Il y a un plug-in Eclipse .
Vous pouvez envoyer la sortie au graphviz. Cependant, la visualisation devient moins compréhensible car le nombre de packages augmente.
Maintenant que CodePro Analytix [mentionné en premier par Fabian Steeg ci-dessus] est gratuit, ça vaut une autre look. Au moins avant l'achat de Google, les instanciations ont produit de manière fiable un excellent logiciel. J'ai joué avec elle quelques années et rappelez-vous aucune plainte autre que le coût.
Un bon essai serait d'inverser votre fichier JAR dans un diagramme de classe. J'ai trouvé ce tutoriel qui explique comment inverser le projet composé de fichiers JAR dans le diagramme de classe UML: http: //www.ejb3.org/jar_file_rverse/jar_file_reverse.html
Vous pourrez inverser au niveau du package au niveau de l'emballage, mais également voir des classes d'un package ayant des relations avec d'autres packages. Une fois que le projet a été inversé, vous pouvez la réorganiser comme modèle et donner cette documentation à l'équipe de mise en œuvre.
C'est exactement le type de cas d'utilisation I construire Degraph pour.
Il vous permet de définir tranches , c'est-à-dire des ensembles de classes qui appartiennent ensemble et les visualisent comme un nœud pliable. Vous seriez des tranches que vous pouvez modifier jusqu'à ce qu'ils n'aient pas plus de dépendances cycliques, auquel ils peuvent devenir leur propre pot.
Cela facilite la comptabilisation des dépendances entre tranches que vous devez casser. Puisque vous pouvez ouvrir le nœud de la tranche et voir toutes les classes contenues, il est également facile d'identifier des refacteurs possibles (introduire des interfaces, des classes mobiles ..) pour atteindre votre objectif.
Je pense que si vous avez besoin d'un outil pour vous indiquer comment organiser vos 5000 classes, vous avez plus de problèmes que cet outil ne peut vous tirer. Bonne chance.
@ Z5H, honnêtement? Pourquoi n'utiliseriez-vous pas un outil pour rechercher des dépendances? La production d'un tel outil est très utile pour la conduite de travaux de refactorisation. N'oubliez pas que ceci est le genre de chose qui vous aide à identifier les nœuds avec un couplage mutuel faible. Ces nœuds peuvent ensuite devenir candidats à des produits de construction séparés séparés. Des temps de construction plus courts pour les changements localisés, etc., sont toutes des motivations fortes pour ce type de refactoring. S'il y a des outils qui aident à souligner «Commencez ici, cette coupe serait facile», pourquoi n'utiliseriez-vous pas une telle chose?
Je venais de "commenter" que si vous êtes au stade où vous avez 5000 classes et que vous n'êtes pas assez d'une architecture d'application pour vous amener dans la bonne direction sans outil, alors cela ressemble à une très mauvaise situation. Ce n'est pas un exercice d'optimisation où un outil vous dit quoi regarder ensuite. C'est la une architecture entière de votre application , laquelle devrait avoir un meilleur gérant. Si vous utilisez l'outil comme vérification des idées, cela semble bon. Si cela dirige votre conception, cela semble effrayant. Vous avez fait sonner comme si l'outil conduirait votre conception.
@ Z5H, non, le code n'est pas l'architecture. Le code est la mise en œuvre. L'architecture peut dessiner les boîtes avec des lignes et dire "Ceci est la conception envisagée". Un outil d'inspection peut parcourir le code et s'assurer qu'aucune des cases de la carte d'architecture n'a de connexion cachée quand elles ne le devraient pas. Par exemple, une "incluse" errante "Inclure" peut introduire une dépendance entre deux pièces de code qui n'auraient jamais dû être couplées, mais une fausse dépendance cachée qui affecte la commande de construction. L'outil peut inspecter votre code pour vous assurer qu'il correspond à l'architecture.