Comment dois-je visualiser la structure de mon code?

L'outil le plus important que vous devez utiliser est votre cerveau, et c'est gratuit.

Il n'y a aucune raison pourquoi vous devez utiliser toute sorte de méthode standard de visualisation, et vous pouvez utiliser n'importe quel support que vous souhaitez. Papier, tableau blanc, photoshop, visio, powerpoint, le bloc-notes: tous ces éléments peuvent être efficaces. Dessinez un diagramme de classes, d'objets, de méthodes, de propriétés, variables - ce que vous pensez est utile de savoir pour comprendre l'application. Le public n'est pas seulement les autres membres de votre équipe, mais aussi vous-même. Créer des diagrammes qui sont utiles pour vous de regarder et de comprendre rapidement. Affichez-les dans votre espace de travail et de les regarder régulièrement afin de vous rappeler de l'architecture globale du système comme vous le construire.

UML et le code des normes de documentation sont de bonnes lignes directrices pour les types de diagrammes que vous pouvez faire et les informations que vous devriez envisager d'inclure. Cependant, il est trop pour la plupart des applications et, fondamentalement, il existe pour les personnes qui ne peuvent pas prendre la responsabilité personnelle pour la documentation de l'absence de normes. Si vous suivez UML à la lettre, vous finirez par passer beaucoup trop de temps sur vos documents plutôt qu'à la création de votre application.

Il est stocké dans plusieurs fichiers. Il utilise différentes classes avec des méthodes différentes. Le code est immense et compliqué.

Tous Java code écrit en dehors de l'école est comme ça, surtout pour un nouveau développeur de départ sur un projet.

C'est une vieille question, mais comme ce qui est à venir dans les recherches Google, j'ajoute ma réponse ici, de sorte qu'il pourrait être utile pour les futurs visiteurs. Permettez-moi également de dire que je suis l'auteur de MaintainJ.

N'essayez pas de comprendre l'ensemble de l'application

Permettez-moi de vous poser cette question - pourquoi voulez-vous comprendre le code? Le plus probablement vous êtes la fixation d'un bug ou d'améliorer une fonctionnalité de l'application. La première chose que vous devriez pas essayer de faire est de comprendre l'ensemble de l'application. En essayant de comprendre l'ensemble de l'architecture tout en repartir sur un projet juste de vous accabler.

Croyez-moi quand je dis que c' - développeurs avec plus de 10 ans de solide expérience du développement peuvent ne pas comprendre comment certaines parties de la demande de travail, même après avoir travaillé sur le même projet depuis plus d'un an (en supposant qu'ils ne sont pas les développeurs à l'origine). Ils peuvent ne pas comprendre comment le fonctionnement de l'authentification ou de la manière dont l'opération de gestion des œuvres dans l'application. Je suis en train de parler typiques d'applications d'entreprise avec 1000 à 2000 classes et à l'aide de différents cadres.

Deux importantes compétences nécessaires à l'entretien de grandes applications

Alors comment font-ils pour survivre et sont payés beaucoup d'argent? Développeurs expérimentés comprennent généralement ce qu'ils font; ce qui signifie, si ils sont à corriger un bug, ils vont trouver l'emplacement de la bogue, corrigez-le et assurez-vous qu'il ne rompt pas le reste de l'application. Si ils ont besoin pour améliorer une fonctionnalité ou d'ajouter une nouvelle fonctionnalité, la plupart du temps, ils ont juste à imiter d'une fonctionnalité existante qui n'a qu'une chose semblable.

Il y a deux compétences importantes qui les aident à le faire.

1. Ils sont en mesure d'analyser l'impact du changement(s) qu'ils font alors que la correction d'un bogue. D'abord qu'ils localiser le problème, modifiez le code et le tester afin de s'assurer qu'il fonctionne. Ensuite, parce qu'ils savent que le langage Java bien et les cadres 'assez bien', ils peuvent dire si ça va casser toutes les autres parties de l'application. Si pas, ils sont fait.

2. J'ai dit que ils ont simplement besoin d'imiter pour améliorer l'application. Pour imiter de manière efficace, il a besoin de savoir Java bien et de comprendre les cadres 'assez bien'. Par exemple, quand ils sont l'ajout d'un nouveau Struts Action de classe et de les ajouter à la configuration xml, ils vont d'abord trouver une fonction similaire, essayez de suivre le flux de la fonctionnalité et de comprendre comment cela fonctionne. Ils peuvent avoir à modifier un peu la configuration (comme la "forme" des données dans la 'demande' qu'en 'session' de la portée). Mais s'ils savent les cadres 'assez bien', ils peuvent facilement le faire.

La ligne du bas est, vous n'avez pas besoin de comprendre ce que tous les 2000 classes sont faites pour corriger un bug ou d'améliorer l'application. Il suffit de comprendre ce qui est nécessaire.

Accent sur la fourniture de valeur immédiate

Ainsi je vous décourager, vous de la compréhension de l'architecture? Non, pas du tout. Tous, je vous demande de réaliser. Une fois que vous commencez un projet et une fois que vous avez mis en place l'environnement de développement sur votre PC, vous ne devriez pas prendre plus d'une semaine pour livrer quelque chose, aussi infime soit-elle. Si vous êtes un programmeur expérimenté et ne permettent pas d'obtenir quoi que ce soit après 2 semaines, comment un manager peut-il savoir si vous avez vraiment de travail ou de lecture de l'actualité sportive?

Donc, pour rendre la vie plus facile pour tout le monde, livrer quelque chose. N'allez pas avec l'attitude que vous avez besoin de comprendre l'ensemble de l'application à réaliser quelque chose de précieux. C'est complètement faux. L'ajout d'une petite et localisée de validation Javascript peuvent être très utiles pour l'entreprise et quand vous le livrer, le manager se sent soulagé qu'il a obtenu une certaine valeur pour son argent. En outre, il vous donne le temps de lire l'actualité sportive.

Comme le temps passe et après vous livrons 5 petites corrections, vous commencez lentement à comprendre l'architecture. Ne sous-estimez pas le temps nécessaire pour comprendre chaque aspect de l'application. Donner 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 préalable sur des applications similaires, mais je suis simplement en train de donner l'ordre de grandeur des estimations. Voler du temps entre la fixation des défauts. Ne demandez pas à l'époque.

Quand vous comprenez quelque chose, écrire des notes, de dessiner la classe/séquence/diagramme de modèle de données.

Diagrammes

Haaa...il m'a fallu si long pour mentionner les diagrammes :). J'ai commencé avec la divulgation que je suis l'auteur de MaintainJ, l'outil qui génère de l'exécution des diagrammes de séquence. Permettez-moi de vous dire comment il peut vous aider.

La grande partie de l'entretien est de localiser la source d'un problème ou à comprendre comment une fonction.

MaintainJ généré des diagrammes de séquence montrent le flux d'appels et de flux de données pour un seul cas d'utilisation. Ainsi, dans un diagramme de séquence simple, vous pouvez voir les méthodes qui sont appelées pour un cas d'utilisation. Donc, si vous êtes à la fixation d'un bug, le bug est le plus probablement dans l'une de ces méthodes. Juste le fixer, de s'assurer qu'il ne casse pas autre chose et de sortir.

Si vous avez besoin pour améliorer la fonctionnalité, de comprendre le flux d'appels de cette fonction en utilisant le diagramme de séquence et ensuite l'améliorer. L'amélioration peut être comme l'ajout d'un champ supplémentaire ou l'ajout d'une nouvelle validation, etc. Généralement, l'ajout d'un nouveau code est moins risqué.

Si vous avez besoin d'ajouter une nouvelle fonctionnalité, trouver une autre fonctionnalité similaire à ce que vous avez besoin de progresser, de comprendre le flux d'appels de cette fonction à l'aide de MaintainJ et ensuite l'imiter.

Semble simple? Il est en fait simple, mais il y aura des cas où vous en fera de plus grandes améliorations comme la construction d'une fonctionnalité totalement nouvelle ou quelque chose qui affecte la conception fondamentale de l'application. Par le temps que vous essayez quelque chose comme ça, vous devez vous familiariser avec l'application et de comprendre l'architecture de l'application raisonnablement bien.

Deux bémols à mon argument ci-dessus

1. Je l'ai mentionné que l'ajout de code est moins risqué que de modifier le code existant. Parce que vous voulez éviter de changer, vous pourriez être tenté de tout simplement copier une méthode existante et d'y ajouter plutôt que de modifier le code existant. Résister à cette tentation. Toutes les applications ont une certaine structure ou la "uniformité". Ne pas le ruiner par de mauvaises pratiques comme la duplication de code. Vous devez savoir lorsque vous êtes en s'écartant de la "uniformité". Demander à un développeur senior sur le projet d'examiner les changements. Si vous devez faire quelque chose qui ne suivent pas les conventions, au moins s'assurer qu'elle est locale à une petite classe (une méthode privée dans un 200 ligne de classe ne serait pas de la ruine de l'application de l'esthétique).

2. Si vous suivez la méthode décrite ci-dessus, si vous pouvez survivre pendant des années dans l'industrie, vous courez le risque de ne pas comprendre les architectures d'application, qui n'est pas bon sur le long terme. Ceci peut être évité en travaillant sur de plus grands changements ou par un peu moins de Facebook temps. Passer du temps à comprendre l'architecture lorsque vous avez un peu libre et du document pour les autres développeurs.

Conclusion

L'accent sur la valeur immédiate et utiliser les outils qui les leur fournir, mais ne soyez pas paresseux. Des outils et des diagrammes d'aide, mais vous pouvez le faire sans eux trop. Vous pouvez suivre mes conseils, simplement en prenant le temps d'un développeur senior sur le projet.

avez-vous essayé Google CodePro Analytix ?

il peut par exemple afficher les dépendances et est gratuit (capture d'écran cod.google.com):

JUDE Communauté UML utilisé pour être en mesure d'importer Java, mais il n'est plus le cas. C'est un bon outil gratuit.

Si votre application est vraiment très complexe, je pense que les diagrammes de ne pas vous emporter très loin. Lorsque les diagrammes deviennent très complexes, ils deviennent difficiles à lire et à perdre de leur puissance. Certains bien choisi schémas, même s'il est généré par la main, peut être suffisant.

Vous n'avez pas besoin de chaque méthode, les paramètres et valeur de retour énoncées. Habituellement, c'est juste que les relations et les interactions entre les objets ou les packages dont vous avez besoin.

Vous pouvez utiliser JArchitect outil, une jolie outil complet pour visualiser la structure du code à l'aide de la graphe de dépendance, et parcourez-vous le code source comme une base de données à l'aide de CQlinq.
JArchitect est gratuit pour open source contributeurs