La voix du code
Une exploration sociologique des traces laissées par nos commits
Pour peu qu’on sache l’écouter, notre code a beaucoup de choses à nous raconter. Surtout si on utilise un système de versioning tel que Git.
C’est en lisant le livre d’Adam Thornhill, Your Code as a Crime Scene, que j’ai appris à entendre cette petite voix, en étudiant comment analyser des informations extraites d’un dépôt Git, à l’aide de techniques simples à mettre en place.
Les dépôts Git ne stockent pas uniquement du code, ils nous racontent également l’histoire des contributeurs et collaborateurs qui l’ont façonné au fil des commits.
Cette série d’articles vise à ajouter une petite pierre à l’édifice à ces pratiques permettant de retracer cette histoire.
Nous verrons ainsi comment un simple graphe, liant les fichiers et les personnes qui les ont modifiés, peut nous révéler des comportements collaboratifs, des points de défaillance organisationnelle ou encore la structure informelle de notre système.
Le conteur Git
Vous le savez déjà : chacun de nos commits contient bien plus de choses que le code enregistré. On y trouve aussi, entre autres, son auteur et sa date.
En croisant ces deux données avec la liste des fichiers modifiés, on peut facilement construire un graphe dans lequel :
chaque auteur est un nœud ;
chaque fichier modifié est également un nœud ;
un lien relie l’auteur avec le fichier qu’il a modifié
Grâce à ce graphe, nous pouvons observer la répartition des responsabilités dans une ou plusieurs équipes et répondre à certaines questions, par exemple :
Quels sont les fichiers les plus « touchés » ? Par qui ?
Est-ce que certains auteurs ont le monopole de la connaissance ?
Quels auteurs travaillent sur les mêmes fichiers ? Sont-ils dans la même équipe ?
Existe-t-il des modules critiques ? Si oui, combien de personnes les maîtrisent ?
Qui sont les « points de passage » entre les sous-systèmes ?
Y a-t-il des silos ? Des zones de friction ?
Nous verrons aussi comment visualiser ces données pour être en mesure de les présenter à son équipe ou à des personnes peu techniques.
Voici un exemple de diagramme que nous construirons ensemble à partir d’un tel graphe et qui permet d’évaluer la position des développeurs dans la culture d’un projet. Sans rentrer dans les détails techniques pour le moment :
Chaque point est un auteur,
Sur l’axe horizontal : plus on va à droite, plus l’auteur est connecté (c’est-à-dire plus l’auteur a modifié de fichiers),
Sur l’axe vertical : plus on monte, plus l’auteur a contribué (commits),
La taille d’un point correspond au nombre de lignes modifiées.
L’analyse est la suivante :
En haut à droite, on trouve les auteurs influents ET actifs,
À droite et en bas, ce sont les auteurs connectés, mais peu actifs
En haut et à gauche, les auteurs très actifs, mais peu connectés (ce sont souvent des développeurs très spécialisés),
En bas et à gauche, ce sont les contributeurs occasionnels ou isolés.
Pourquoi ces questions sont importantes ?
Un bon design va souvent de pair avec une bonne organisation sociale. Par exemple :
un fichier modifié par dix personnes en continu est peut-être un indice que l’architecture a un problème.
un module maîtrisé par une seule personne nécessite probablement que l’on revoit le partage de la connaissance au sein d’une équipe.
Analyser la structure sociale de votre dépôt, c’est comme prendre soin de la santé de votre produit.
Intéressé.e pour en savoir plus ? Si oui, j’espère vous retrouver dans les prochains articles dans lesquels nous verrons comment :
Extraire des données utiles d’un dépôt
Construire un graphe à partir de ces données
Le visualiser
Détecter des patterns organisationnels
Identifier les ponts, les silos
Et transformer ces analyses en actions concrètes
À bientôt !
#substack #code-analysis