Il y a deux semaines a eu lieu le JUG de Lausanne sur l’analyse de la qualité du code. J’en ai été l’organisateur et la publication de la vidéo de cet événement m’a donné l’occasion de le revivre et m’a donné envie de le commenter. Voilà donc mes impressions personnelles sur cet événement.
Marc Cherfi, membre de l’équipe XDepend animera le stand dédié au logiciel à l’Université du SI les 1er et 2 juillet prochains. Aujourd’hui il nous parle des standards de qualité du logiciel, du positionnement de XDepend sur le marché et de son intervention à l’USI.
(Lire la suite…)
En ingénierie logicielle, tant qu’un projet se développe, la dette technique s’accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c’est qu’elle n’est pas vraiment mesurable, et comme l’iceberg, on n’en voit que la partie émergée. Résultat, le refactoring est souvent sous-estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal. Plus personne n’a l’audace de le tenter, et à long terme, c’est la banqueroute assurée du projet.
L’objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d’un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l’étape de refactoring et trouver les zones à refactorer.
Pour rendre l’article concret, nous allons utiliser à titre d’exemple XDepend qui est un outil d’analyse de code statique java. En effet, on parle d’amélioration de la qualité, donc pour juger de l’efficacité de nos actions, il faut pouvoir les mesurer. (Lire la suite…)
