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 ça, en particulier pour un nouveau développeur qui commence un projet.
Il s'agit d'une ancienne question, mais comme elle apparaît dans les recherches Google, j'ajoute ma réponse ici afin qu'elle puisse être utile aux futurs visiteurs. Permettez-moi également de préciser que je suis l'auteur de MaintenirJ .
N'essayez pas de comprendre l'ensemble de l'application
Laissez-moi vous poser la question suivante : pourquoi voulez-vous comprendre le code ? Il est fort probable que vous soyez en train de corriger un bogue ou d'améliorer 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'ensemble de l'architecture en commençant un nouveau projet ne fera que vous submerger.
Croyez-moi quand je dis ceci : des développeurs ayant plus de 10 ans d'expérience solide en codage peuvent ne pas comprendre comment certaines parties de l'application fonctionnent même après avoir travaillé sur le même projet pendant plus d'un an (en supposant qu'ils ne soient pas les développeurs originaux). Ils peuvent ne pas comprendre comment l'authentification fonctionne ou comment la gestion des transactions fonctionne dans l'application. Je parle ici d'applications d'entreprise typiques comportant 1000 à 2000 classes et utilisant différents frameworks.
Deux compétences importantes requises pour la maintenance de grandes applications
Alors comment font-ils pour survivre et être payés grassement ? Les développeurs expérimentés comprennent généralement ce qu'ils font ; autrement dit, s'ils doivent corriger un bogue, ils trouveront l'emplacement du bogue, puis le corrigeront et s'assureront qu'il ne casse pas le reste de l'application. S'ils doivent améliorer une fonctionnalité ou en ajouter une nouvelle, la plupart du temps, il leur suffit d'imiter une fonctionnalité existante qui fait une chose similaire.
Deux compétences importantes les aident à le faire.
-
Ils sont capables d'analyser l'impact du ou des changements qu'ils effectuent en corrigeant un bogue. Ils commencent par localiser le problème, modifient le code et le testent pour s'assurer qu'il fonctionne. Ensuite, parce qu'ils connaissent bien le langage Java et les frameworks, ils peuvent dire si cela va casser d'autres parties de l'application. Si ce n'est pas le cas, ils ont terminé.
-
J'ai dit qu'ils devaient simplement imiter pour améliorer l'application. Pour imiter efficacement, il faut bien connaître Java et comprendre les frameworks "suffisamment bien". Par exemple, lorsqu'ils ajoutent une nouvelle classe Struts Action et l'ajout au xml de configuration, ils vont d'abord trouver une fonctionnalité similaire, essayer de suivre le flux de cette fonctionnalité et comprendre comment elle fonctionne. Il se peut qu'il doive modifier un peu la configuration (par exemple, les données du "formulaire" se trouvent dans la portée de la "requête" plutôt que dans celle de la "session"). Mais s'ils connaissent suffisamment bien les frameworks, ils peuvent facilement le faire.
L'essentiel est que, vous n'avez pas besoin de comprendre ce que font les classes 2000 pour corriger un bug ou améliorer l'application. Comprenez juste ce qui est nécessaire.
Se concentrer sur la fourniture d'une 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 tenir vos promesses. Une fois que vous commencez un projet et 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 petit soit-il. Si vous êtes un programmeur expérimenté et que vous ne livrez rien après deux semaines, comment un responsable peut-il savoir si vous travaillez vraiment ou si vous lisez les nouvelles sportives ?
Donc, pour faciliter la vie de tout le monde, livrer quelque chose. N'allez pas croire que vous devez comprendre l'ensemble de l'application pour fournir quelque chose de valable. C'est complètement faux. L'ajout d'une petite validation Javascript localisée peut être très utile à l'entreprise et, lorsque vous la livrez, le responsable se sent soulagé d'en avoir eu pour son argent. De plus, cela vous donne le temps de lire les nouvelles sportives.
Au fil du temps et après avoir livré 5 petits correctifs, 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 sur des applications similaires, mais je ne donne que des estimations approximatives. Volez le temps entre la correction des défauts. Ne demandez pas ce temps.
Lorsque vous comprenez quelque chose, prenez des notes ou dessinez le diagramme de classe/séquence/modèle de données.
Diagrammes
Haaa...il m'a fallu si longtemps pour mentionner les diagrammes :). J'ai commencé par révéler que je suis l'auteur de MaintainJ, l'outil qui génère des diagrammes de séquence en temps réel. Laissez-moi vous dire comment il peut vous aider.
Une grande 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 seul cas d'utilisation. Ainsi, dans un diagramme de séquence simple, vous pouvez voir quelles méthodes sont appelées pour un cas d'utilisation. Donc, si vous corrigez un bogue, le bogue se trouve très probablement dans l'une de ces méthodes. Il suffit de le corriger, de s'assurer qu'il ne casse rien d'autre et de sortir.
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-la. L'amélioration peut consister à ajouter un champ supplémentaire ou à ajouter une nouvelle validation, etc. En général, l'ajout de nouveau code est moins risqué.
Si vous devez ajouter une nouvelle fonctionnalité, trouvez une autre fonctionnalité similaire à celle que vous devez développer, comprenez le flux d'appels de cette fonctionnalité à l'aide de MaintainJ, puis imitez-la.
Cela semble simple ? En fait, c'est simple, mais il y aura des cas où vous devrez apporter des améliorations plus importantes, comme la création d'une toute nouvelle fonctionnalité ou quelque chose qui affecte la conception fondamentale de l'application. Au moment où vous vous lancez dans une telle entreprise, vous devez être familiarisé avec l'application et en comprendre raisonnablement bien l'architecture.
Deux réserves à mon argument ci-dessus
-
J'ai mentionné que l'ajout de code est moins risqué que la modification du code existant. Comme vous voulez éviter de changer, vous pouvez être tenté de copier simplement une méthode existante et d'y ajouter du code plutôt que de modifier le code existant. Résistez à cette tentation. Toutes les applications ont une certaine structure ou "uniformité". Ne la gâchez pas par de mauvaises pratiques comme la duplication de code. Vous devez savoir quand vous vous écartez de cette "uniformité". Demandez à un développeur senior du projet de revoir les changements. Si vous devez faire quelque chose qui ne suit pas les conventions, assurez-vous au moins que c'est local à une petite classe (une méthode privée dans une classe de 200 lignes ne ruinerait pas l'esthétique de l'application).
-
Si vous suivez l'approche décrite ci-dessus, vous pouvez certes survivre pendant des années dans le secteur, mais vous courez le risque de ne pas comprendre les architectures d'application, ce qui n'est pas bon à long terme. Ce risque peut être évité en travaillant sur des changements plus importants ou en consacrant moins de temps à Facebook. Passez du temps à comprendre l'architecture lorsque vous êtes un peu libre et documentez-la pour les autres développeurs.
Conclusion
Concentrez-vous sur la valeur immédiate et utilisez les outils qui y contribuent, mais ne soyez pas paresseux. Les outils et les diagrammes sont utiles, mais vous pouvez aussi vous en passer. Vous pouvez suivre mon conseil en prenant simplement le temps d'un développeur senior sur le projet.
