Introduction

J’aime beaucoup le livre d’Adam Tornhill qui décrit comment exploiter l’historique d’un repository de code pour identifier des pistes de refactoring et comprendre comment l’équipe de développement influence le design.

Les exemples du s’appuie sur un outil open source nommé code-maat et sur des scripts écrits dans différents langages pour générer les visualisations¹.

L’un des soucis est que des tâches manuelles sont nécessaires pour intégrer ces outils dans le contexte d’un projet qu’on souhaiterait analyser.

gocan rassemble en un seul outil ces fonctionnalités et simplifie l’analyse de projets Git.

Cet article décrit comment utiliser gocan pour analyser quelques projets open source.

Installer gocan

Il y a plusieurs façons d’installer gocan:

• à l’aide d’Homebrew pour les utilisateurs Mac & Linux
• utiliser une image Docker (mais c’est moins pratique)
• récupérer le code source du projet et construire le binaire en local

Pour le reste de cet article, je vais considérer que la première option a été choisie.

Lancer Une Analyse

La première étape consiste à démarrer la base de données embarquée de l’outil: celle-ci contiendra les résultats des analyses et permet éventuellement de comparer les données sur des périodes différentes:

gocan start-db

Ensuite, nous devons créer une scène qui contiendra une ou plusieurs applications à analyser à l’aide de la commande suivante:

gocan create-scene tutorial

L’étape suivante consiste à créer l’application à analyser et à l’ajouter à la scène. Comme dans le livre qui a inspiré gocan, nous allons commencer par analyser hibernate:

gocan create-app hibernate --scene tutorial

Maintenant, nous devons récupérer le repo Git à analyser:

cd workspace
git clone https://github.com/hibernate/hibernate-orm.git

A présent, nous pouvons lancer l’analyse sur l’historique:

cd hibernate-orm
gocan import-history hibernate --scene tutorial --after 2011-01-01 --before 2013-09-14

L’opération va prendre plusieurs minutes, un peu de patience est éventuellement nécessaire selon vos limites.

Quelques mots sur les options choisies ici:

• after et before permettent de restreindre la période sur laquelle on souhaite importer les données. Il n’est pas recommandé d’importer toutes les informations d’un projet depuis le début de son existence, cela risque de fausser les analyses.

En terme de stockage, gocan ne garde pas le code source analysé, simplement les métriques qui l’intéressent. Il conserve également les noms des développeurs responsables des commits mais il est possible de les anonymiser ensuite si désiré.

Visualiser les données

Nous pouvons maintenant (enfin !) visualiser les informations récoltées. Pour cela, gocan embarque également un petit serveur web que vous pouvez lancer avec la commande suivante:

gocan ui

Par defaut, le serveur écoute sur le port 1233 donc si vous ouvrez un navigateur à l’adresse http://localhost:123, vous devriez voir une page similaire à celle ci:

Oui, je sais: c’est très minimaliste pour le moment.

Cette page contient la liste de toutes les scènes créées (c’est à dire une seule jusqu’à présent). Si vous sélectionnez la scène tutorial, vous serez redirigé vers la liste des applications de cette scène (une seule ici encore):

Cette page est un petit résumé de l’analyse effectuée pour chaque application. Elle contient:

• la période analysée
• le nombre de commits
• le nombre d’entités (en gros, les fichiers)
• le nombre de changements
• le nombre d’auteurs

Révisions

Maintenant, sélectionnons l’application hibernate:

Voici enfin notre première visualisation graphique !

Cet onglet affiche le nombre de révisions par fichier sur la période analysée et triée par nombre de révisions décroissants³.

Je l’utilise pour expliquer qu’en général les modifications sont concentrées sur un petit nombre de fichiers et que ce sont ces modifications nombreuses qui sont susceptibles d’indiquer et/ou d’introduire des problèmes dans le code.

S’il y a du refactoring à faire, ce sera probablement sur les fichiers les plus souvents modifiés afin de les stabiliser.

Bien sûr, il est également possible que les fichiers concernés soient souvent modifiés pour de bonnes raisons (fichiers de config, features en cours de dév, …). Il faut donc toujours utiliser ces analyses comme des guides et surtout pas comme des sources de vérité.

La vue graphique est bien jolie mais comment savoir quels sont les noms des fichiers les plus utilisés ? Pas de panique, on peut utiliser une commande gocan à cette fin:

gocan revisions hibernate --scene tutorial | head -n 11

Cette commande retourne le top 10 (l’entête ne compte pas) des fichiers les plus souvent commités:

entity                                                                                                                                                                        n-revs    code
build.gradle                                                                                                                                                                  188       385
hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java                                                                                      85        3983
hibernate-core/src/main/java/org/hibernate/cfg/Configuration.java                                                                                                             78        2677
hibernate-core/src/main/java/org/hibernate/internal/SessionFactoryImpl.java                                                                                                   77        1386
hibernate-core/hibernate-core.gradle                                                                                                                                          63        119
hibernate-core/src/main/java/org/hibernate/metamodel/binding/EntityBinding.java                                                                                               62        415
hibernate-core/src/main/java/org/hibernate/metamodel/source/internal/MetadataImpl.java                                                                                        60        472
hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java                                                                                                               54        993
hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java                                                                                                          51        2097
hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/entity/EntityBinder.java                                                                              49        0

On voit que le fichier le plus modifié est le fichier build.gradle: il sert à construire l’application et est probablement un faux positif (il faudrait discuter avec l’équipe hibernate pour s’en assurer).

Les fichiers AbstractEntityPersister.java et Configuration.java sont les suivants et semblent plus intéressants à étudier. On y reviendra…⁴

Hotspots

Sélectionnons l’onglet Hotspots à présent:

Cette vue permet de visualiser les points chauds du code: chaque cercle représente soit un répertoire soit un fichier.

Plus un fichier a été modifié, plus il sera rouge. Plus il sera complexe, plus le diamètre du cercle le représentant sera élevé.

Typiquement, ce diagramme nous permet d’identifier rapidement les fichiers les plus complexes qui sont le plus souvent modifiés et donc potentiellement source de problèmes.

Il est possible de zoomer dans les zones intéressantes pour repérer les suspects potentiels:

Sans surprise, on retrouve un de nos candidats précédents: AbstractEntityPersister.java.

Code Churn

Si vous sélectionnez l’ongle Code Churn, vous devriez obtenir le diagramme suivant:

Cette visualisation permet d’observer les pics de commits (ajouts ou suppression de code) pendant la période analysée. Elle est très utile pour identifier les patterns de commits d’une équipe: font-ils du trunk-based-development ? des merge request ? les pics ont-ils lieu à la fin des itérations ? …

Il est toujours risqué d’intégrer plusieurs grosses quantités de modifications d’un seul coup dans la branche principale, c’est donc un bon moyen d’étudier ce point ici.

Modus Operandi

Cette vue recense les mots les plus souvent utilisés dans les messages des commits. Elle donne une idée de ce sur quoi l’équipe travaille le plus souvent: est-ce que ce sont des corrections de bugs ? des nouvelles features ? etc.

Knowledge Map

Terminons enfin notre article avec la Knowledge Map qui nous permet de visualiser la distribution de la connaissance des différents fichiers.

gocan détermine une couleur pour chaque auteur et l’associe aux fichiers auxqels il a le plus contribué. Il est ainsi possible de voir qui connaît quoi et savoir à qui s’adresser pour comprendre comment fonctionne une partie du code donnée.

Je me sers souvent de cette vue pour discuter également du Bus Factor et de l’importance du partage de connaissances, idéalement par le pairing éventuellement complété par de la doc ou autre.

Conclusion

C’est ici que se termine notre petit tour d’exploration avec gocan.

J’espère que cet article vous aura donné envie de tester l’outil sur vos projets perso ou pro.

Il y a encore bien d’autres choses à visualiser mais ce sera l’objet d’un futur article, patience :-)