Le développement d'une application est un travail d'équipe. Il faut des compétences complémentaires pour qu'elle fonctionne bien. Or, les bugs sont fréquents et il n'est pas facile de lire le code et toutes ses interdépendances. Le plus simple serait donc d'appeler votre collègue qui a travaillé dessus, mais il a une grippe et ne peut pas vous répondre. Pour éviter ce genre de situations, nous utilisons des outils qui nous aident à visualiser le codebase de l'application. Dans cet article, nous allons vous présenter l'un d'entre eux que nous utilisons fréquemment : Moose.
Le développement d'applications est une tâche fastidieuse ! Ce n'est pas comme éditer un document Word. Le code n'est pas linéaire. En fait, le code peut être vu comme un graphique. Les classes, les méthodes et les attributs sont des nœuds connectés à d'autres. Lors de l'exécution d'un algorithme, il faut suivre les relations entre tous ces nœuds pour comprendre le programme.
La plupart des développeurs sont habitués à une visualisation UML (Unified Modeling Language) ou à une représentation architecturale de leur code. Ces types de représentations sont excellents car ils sont compréhensibles par tous, mais ils ne représentent pas nécessairement notre problèmatique. De plus, elles sont souvent dépassées, ou trop grandes (dans le cas d'énormes applications) pour être compréhensibles.
Pour améliorer la compréhension de nos systèmes, des personnes ont développé des outils automatiques qui analysent notre base de code et nous donnent une visualisation pré-construite ainsi que des outils pour créer la nôtre. L'un des acteurs majeurs pour analyser les systèmes logiciels est Moose.
Pourquoi visualisons-nous le code chez Berger-Levrault ?
Lorsqu'elles développent des applications, nos équipes utilisent plusieurs outils pour les aider : Des environnements de développement intégrés (IDE) comme Eclipse, VSCode ou Intellij Idea, des outils pour tester automatiquement leur code comme GitLab CI, des outils pour évaluer la qualité de leur code comme SonarQube, et des outils pour évaluer la couverture du code (SonarQube, encore). Nous utilisons également des outils pour gérer les modifications que nous devons effectuer sur un système logiciel comme Jira ou GitLab.
Tous ces outils permettent d'évaluer la qualité du projet ou de gérer les modifications. Mais ils n'aident pas à comprendre les systèmes logiciels. La compréhension d'un système logiciel est cependant essentielle lors de la maintenance de grandes applications. Quelle est la partie de mon système que je dois modifier le plus ? Où sont implémentés les codes métiers, liés à quels tickets Jira ? Quelles sont les dépendances du code et comment en supprimer certaines pour rendre les fonctionnalités indépendantes les unes des autres ? Pour résoudre ce problème, je dois modifier cette classe, et quelles autres ? Les développeurs nouvellement arrivés peuvent-ils travailler sur l'application et la maintenir correctement et rapidement ? Toutes ces questions sont cruciales pour maintenir de grandes applications au fil des ans. Cependant, souvent, les gens pensez à ils ont une bonne connaissance du système logiciel car ils viennent de le développer.
La visualisation permet de répondre à toutes ces questions. Plus encore, la visualisation, basée sur des métriques, mettra en évidence le problème et contribuera ainsi à améliorer le système logiciel et à réduire la dette technique. Et rappelez-vous, ce n'est pas parce que quelqu'un a développé une application que cette personne a une bonne connaissance du système logiciel.
La plateforme Moose
Moose est une plateforme open-source pour l'analyse de logiciels basée sur Pharo. Il nous permet de représenter les systèmes logiciels dans des modèles, et d'interroger, de manipuler, de transformer, de visualiser ces modèles. Avec Moose, le processus d'analyse d'un nouveau projet est plutôt simple :
- Donnez à Moose votre base de code
- Moose l'importe dans un modèle
- Moose génère des rapports et des visualisations de votre code.
- Manipuler les informations sur l'élan
Quelques exemples
Moose est utilisé par l'équipe DRIT pour mieux comprendre le code de notre application. Comme nous ne sommes pas des experts métier, Moose nous est utile pour comprendre l'architecture de l'application qui est influencée par le domaine métier. Par exemple, nous pouvons l'utiliser pour récupérer l'architecture de l'application.
Architecture des services
Par exemple, une de nos préoccupations est d'extraire l'architecture des services. Les services de l'application sont-ils bien séparés, ou existe-t-il des dépendances croisées qui pourraient créer des erreurs lors de la transformation d'une application monolithique en une application micro-services ?
Maintenir la base de code
Quelle partie de votre base de code présente le plus de bugs ? A besoin de plus de maintenance ? Et tous les développeurs maintiennent-ils toutes les parties du code ? Ou bien un seul développeur maintient-il une partie critique du code de base ?
La figure ci-dessus présente les classes d'un projet BL. Chaque carré correspond à une classe et chaque couleur est un développeur (ou un groupe de développeurs pour le carré rouge). En utilisant cette visualisation, il est possible de déterminer que certains paquets ne sont maintenus que par un seul développeur. Que se passe-t-il si ce développeur décide de quitter l'entreprise ? Nous pouvons maintenant facilement demander à d'autres développeurs d'apprendre différentes parties du système pour être plus résilient.
Une autre visualisation est la HeatMap. Elle permet de trouver rapidement les fichiers les plus modifiés dans les commits récents, et les issues/tickets Jira associés à la modification. Ce genre de représentations est particulièrement intéressante pour détecter le code qui est plus sujet à modification et donc, le code qui doit être plus testé.
Visualisation classique
Enfin, qui peut faire plus peut faire moins.
En plus de l'analyse spécifique, il est également possible d'effectuer d'autres analyses du code. Par exemple : générer l'UML à partir d'un ensemble de classes, trouver les dépendances en utilisant une représentation DSM (ou un graphe), utiliser la carte de distribution et la complexité du système pour découvrir les mauvaises odeurs et les classes complexes, et éliminer les duplications grâce à un algorithme avancé de recherche de duplications.
Faites encore plus que visualiser votre code
Visualiser votre base de code, c'est bien, mais vous pouvez faire plus. Par exemple, Moose est livré avec des outils pour manipuler les modèles. Ainsi, il est possible d'effectuer un refactoring en utilisant toute la puissance de l'outil. Un exemple connu chez Berger-Levrault est l'application Casino, , un outil qui effectue la migration des front-ends d'applications vers Angular. Cet outil est entièrement développé à l'aide de la plateforme Moose.
Pour terminer cet article, je vous présente le feu d'artifice : une visualisation de l'interface utilisateur de l'une des applications BL.
