Comment dois-je visualiser la structure de mon code?
J'ai une application écrite en Java. In est stocké dans plusieurs fichiers. Il utilise différentes classes avec différentes méthodes. Le code est gros et compliqué. Je pense qu'il serait plus facile de comprendre le code si j'ai un modèle graphique du code (une sorte de graphe dirigé). Existe-t-il des méthodes standard pour la visualisation du code? Je pense à l'utilisation de UML (je ne suis pas sûr que ce soit un choix correct). Quelqu'un peut-il me recommander quelque chose?
AJOUTÉE:
Je considère deux possibilités:
- Création du graphique à la main (explicitement).
- Création graphique de manière automatique. Par exemple, utiliser des outils qui lisent le code disponible et génèrent un graphique décrivant la structure du code.
AJOUT 2:
Ce serait bien d'avoir quelque chose gratuitement.
L'outil le plus important que vous devriez utiliser est votre cerveau, et c'est gratuit.
Il n'y a aucune raison pour que vous utilisiez une méthode de visualisation standard, et vous pouvez utiliser le support de votre choix. Papier, tableau blanc, photoshop, visio, PowerPoint, bloc-notes: tout cela peut être efficace. Dessinez un diagramme de classes, d'objets, de méthodes, de propriétés, de variables - tout ce que vous jugez utile de voir pour comprendre l'application. Le public n'est pas seulement les autres membres de votre équipe, mais aussi vous-même. Créez des diagrammes utiles à regarder et à comprendre rapidement. Publiez-les dans votre espace de travail et consultez-les régulièrement pour vous rappeler l'architecture globale du système au fur et à mesure de sa construction.
UML et les autres normes de documentation de code constituent de bonnes directives pour les types de diagrammes que vous pouvez créer et les informations à inclure. Cependant, il est excessif pour la plupart des applications et existe essentiellement pour les personnes qui ne peuvent assumer la responsabilité de documenter sans normes. Si vous suivez UML à la lettre, vous finirez par consacrer beaucoup trop de temps à la documentation au lieu de créer votre application.
Il est stocké dans plusieurs fichiers. Il utilise différentes classes avec différentes méthodes. Le code est gros et compliqué.
Tout le code Java écrit en dehors de l’école est comme cela, en particulier pour un nouveau développeur qui commence un projet.
C'est une vieille question, mais comme cela est à venir dans les recherches Google, j'ajoute ma réponse ici afin qu'elle puisse être utile aux futurs visiteurs. Permettez-moi également de révéler que je suis l'auteur de MaintainJ .
_ {N'essayez pas de comprendre toute l'application
Permettez-moi de vous demander ceci - pourquoi voulez-vous comprendre le code? Très probablement, vous corrigez un bogue ou améliorez une fonctionnalité de l'application. La première chose que vous ne devriez pas essayer de faire est de comprendre l’ensemble de l’application. Essayer de comprendre l’architecture tout en recommençant un projet ne peut que vous submerger.
Croyez-moi, les développeurs qui possèdent plus de 10 ans d'expérience en codage peuvent ne pas comprendre le fonctionnement de certaines parties de l'application même après avoir travaillé sur le même projet pendant plus d'un an (en supposant qu'ils ne sont pas les développeurs d'origine). Ils peuvent ne pas comprendre comment fonctionne l'authentification ou la gestion des transactions dans l'application. Je parle d'applications d'entreprise typiques avec 1000 à 2000 classes et utilisant différents cadres.
_ {Deux compétences importantes requises pour gérer des applications volumineuses} _
Alors, comment survivent-ils et gagnent-ils beaucoup d'argent? Les développeurs expérimentés comprennent généralement ce qu'ils font. ce qui signifie que s'ils doivent réparer un bogue, ils trouveront l'emplacement du bogue, puis le répareront et s'assureront qu'il ne casse pas le reste de l'application. S'ils ont besoin d'améliorer une fonctionnalité ou d'ajouter une nouvelle fonctionnalité, il leur suffit la plupart du temps d'imiter une fonctionnalité existante qui fait la même chose.
Deux compétences importantes les aident à le faire.
Ils sont en mesure d’analyser l’impact des modifications apportées lors de la correction d’un bogue. Ils localisent d'abord le problème, modifient le code et le testent pour s'assurer qu'il fonctionne. Ensuite, comme ils connaissent bien le langage Java et les frameworks, ils peuvent dire s'il va détruire d'autres parties de l'application. Sinon, ils sont terminés.
J'ai dit qu'ils doivent simplement imiter pour améliorer l'application. Pour bien imiter, il est nécessaire de bien connaître Java et de bien comprendre les frameworks. Par exemple, lorsqu'ils ajoutent une nouvelle classe Struts Action et au xml de configuration, ils rechercheront tout d'abord une fonctionnalité similaire, essayeront de suivre le flux de cette fonctionnalité et de comprendre son fonctionnement. Ils devront peut-être modifier un peu la configuration (par exemple, les données de 'formulaire' se trouvant dans le champ 'demande' que dans le champ 'session'). Mais s’ils connaissent assez bien les cadres, ils peuvent le faire facilement.
En bout de ligne, vous n'avez pas besoin de comprendre ce que toutes les 2000 classes font pour corriger un bogue ou améliorer l'application. Comprenez simplement ce qui est nécessaire.
_ {Concentrez-vous sur la création de valeur immédiate} _
Alors, est-ce que je vous décourage de comprendre l'architecture? Non pas du tout. Tout ce que je vous demande, c'est de livrer. Une fois que vous avez démarré un projet et une fois que vous avez configuré l'environnement de développement sur votre PC, vous ne devriez pas prendre plus d'une semaine pour livrer quelque chose, aussi petit soit-il. Si vous êtes un programmeur expérimenté et ne livrez rien après deux semaines, comment un responsable peut-il savoir si vous travaillez réellement ou si vous lisez des actualités sportives?
Donc, pour rendre la vie plus facile pour tout le monde, livrer quelque chose. N'acceptez pas l'attitude selon laquelle vous devez comprendre l'ensemble de l'application pour fournir quelque chose de précieux. C'est complètement faux. L'ajout d'une validation Javascript petite et localisée peut s'avérer très utile pour l'entreprise. Lorsque vous la transmettez, le responsable se sent soulagé de voir qu'il en a pour son argent. De plus, cela vous donne le temps de lire les nouvelles sportives.
À mesure que le temps passe et que vous apportez 5 petites corrections, vous commencerez à comprendre lentement l'architecture. Ne sous-estimez pas le temps nécessaire pour comprendre chaque aspect de l'application. Donnez 3-4 jours pour comprendre l'authentification. Peut-être 2-3 jours pour comprendre la gestion des transactions. Cela dépend vraiment de l'application et de votre expérience antérieure avec des applications similaires, mais je ne fais que donner des estimations approximatives. Voler le temps entre la réparation des défauts. Ne demandez pas pour ce moment.
Lorsque vous comprenez quelque chose, écrivez des notes ou dessinez le diagramme de classe/séquence/modèle de données.
Diagrammes
Haaa ... ça m'a pris si longtemps pour parler de diagrammes :). J'ai commencé par dire que je suis l'auteur de MaintainJ, l'outil qui génère des diagrammes de séquence d'exécution. Laissez-moi vous dire comment cela peut vous aider.La majeure partie de la maintenance consiste à localiser la source d’un problème ou à comprendre le fonctionnement d’une fonctionnalité.
Les diagrammes de séquence générés par MaintainJ montrent le flux d'appels et le flux de données pour un cas d'utilisation unique. Ainsi, dans un simple diagramme de séquence, vous pouvez voir quelles méthodes sont appelées pour un cas d'utilisation. Donc, si vous corrigez un bogue, il s’agit probablement d’une de ces méthodes. Réparez-le, assurez-vous qu'il ne casse pas autre chose et sortez.
Si vous devez améliorer une fonctionnalité, comprenez le flux d'appels de cette fonctionnalité à l'aide du diagramme de séquence, puis améliorez-le. L'amélioration peut ressembler à l'ajout d'un champ supplémentaire ou à l'ajout d'une nouvelle validation, etc. En général, l'ajout d'un nouveau code est moins risqué.
Si vous devez ajouter une nouvelle fonctionnalité, trouvez-en une autre similaire à ce que vous devez développer, comprenez le flux d'appels de cette fonctionnalité à l'aide de MaintainJ, puis imitez-le.
Cela semble simple? C'est en fait simple, mais dans certains cas, vous apporterez des améliorations plus importantes, telles que la création d'une fonctionnalité entièrement nouvelle ou quelque chose qui affecte la conception fondamentale de l'application. Au moment où vous essayez quelque chose comme ça, vous devriez être familiarisé avec l'application et comprendre l'architecture de l'application assez bien.
Deux mises en garde à mon argument ci-dessus.
Conclusion
Concentrez-vous sur la valeur immédiate et utilisez les outils qui le permettent, mais ne soyez pas paresseux. Les outils et les diagrammes vous aident, mais vous pouvez également vous en passer. Vous pouvez suivre mes conseils en prenant juste le temps d'un développeur senior sur le projet.
Focus on immediate value and use the tools that deliver that, but don't be lazy. Tools and diagrams help, but you can do without them too. You can follow my advice by just taking some time of a senior developer on the project.
Quelques plugins que je connais pour Eclipse:
Architexa
nWire
Si vous souhaitez procéder au reverse engineering du code, vous devez essayer Enterprise Architect
avez-vous essayé Google CodePro Analytix ?
il peut par exemple afficher des dépendances et est gratuit (capture d'écran de cod.google.com):
Voici un outil non UML qui a de très jolies fonctionnalités de visualisation.
Vous pouvez mapper les lignes de code par classe/méthode sur les couleurs/la longueur des rectangles . Vous pouvez également afficher les dépendances entre les classes.
http://www.moosetechnology.org/
La bonne chose est que vous pouvez utiliser les scripts Smalltalk pour afficher ce dont vous avez besoin: http://www.moosetechnology.org/docs/faq/JavaModelManipulation }
Vous pouvez voir ici à quoi ressemble une telle visualisation: http://www.moosetechnology.org/tools/moosejee/casestudy
JUDE Community UML avait l'habitude de pouvoir importer Java, mais ce n'est plus le cas. C'est un bon outil gratuit.
Si votre application est vraiment complexe, je pense que les diagrammes ne vous mèneront pas très loin. Lorsque les diagrammes deviennent très complexes, ils deviennent difficiles à lire et perdent leur pouvoir. Certains diagrammes bien choisis, même s'ils sont générés à la main, peuvent suffire.
Vous n'avez pas besoin d'indiquer chaque méthode, paramètre et valeur de retour. Généralement, il vous faut uniquement les relations et les interactions entre objets ou packages.
Voici un autre outil qui pourrait faire l'affaire: http://xplrarc.massey.ac.nz/
Vous pouvez utiliser l’outil JArchitect , un outil assez complet pour visualiser la structure de votre code à l’aide du graphe dependency , et parcourir le code source comme une base de données utilisant CQlinq . JArchitect est gratuit. contributeurs open source
Quelques bons outils que j'utilise -
StarUML (permet la conversion de code en diagramme)
MS Visio
XMind (très très utile pour une vue d'ensemble du système)
Stylo et papier!