Comment ça marche

La complexité

Une mesure structurelle du code d'un fichier : nombre de chemins d'exécution, imbrication, taille des unités. Plus elle est haute, plus le fichier est coûteux à lire et à modifier sans erreur. Contrairement à la fréquence de modification, il existe des seuils communément admis au-delà desquels un fichier devient difficile à tenir.

La fréquence de modification

Le nombre de commits touchant le fichier sur la fenêtre analysée, et le nombre d'auteurs distincts. Il n'existe pas de seuil absolu : un fichier de configuration modifié chaque semaine est normal, un moteur de calcul modifié chaque semaine l'est moins. C'est pourquoi ce signal est toujours exprimé en percentile, relativement aux autres fichiers du même dépôt.

Le score

Chaque fichier reçoit un score composite fondé sur ses deux percentiles. Le score de santé du dépôt agrège ces valeurs. Il est relatif au dépôt lui-même : il ne permet pas de comparer deux projets entre eux.

Les quatre catégories

• Zone chaude

  Croisement des deux signaux : ce fichier occupe l'équipe et résiste à la lecture.

• Complexe mais stable

  Complexité élevée, historique calme : le coût reste latent.

• Modifié souvent, simple

  Le rythme de changement est soutenu mais le fichier reste lisible.

• Sain

  Complexité et fréquence de modification restent basses.

Limites connues

• —En dessous d'un certain nombre de fichiers analysables, aucun score relatif n'est calculé — comparer dix fichiers entre eux ne veut pas dire grand-chose.
• —La version actuelle n'analyse que le Java. Les autres fichiers sont listés comme non pris en charge et exclus du calcul.
• —Selon que l'historique est lu via l'API GitHub ou via un clone, les fichiers renommés peuvent présenter un historique de modifications différent.
• —L'analyse porte sur une fenêtre de commits, pas sur toute la vie du projet.