E. Audit & Analyse de classe ‐ Détails des métriques & fonctionnalités - uha-fr/endyear_2025_gr11_back GitHub Wiki

Ci-dessous, chaque métrique et fonctionnalité collectée par l’audit et l’analyse de classe est définie, expliquée en détail et illustrée par un exemple ou un cas d’usage.

• Définition : Nombre total de commits réalisés par chaque contributeur.

• Permet de mesurer l’activité individuelle : qui contribue le plus, détecter les « silent contributors » ou les étudiants qui n’ont quasiment pas participé.

• Comment c’est calculé : PyDriller parcourt tous les commits du dépôt ; pour chaque commit, on lit commit.author.name et on incrémente un Counter[auteur] de 1.

• Interprétation : Un auteur avec très peu de commits peut indiquer un travail de groupe déséquilibré ou un outil de commit automatisé minimal. Un pic de commits juste avant une deadline peut signaler du “rush coding”.

• Exemple : Commits par auteur :

Alice : 42 commits
Bob   : 27 commits
Carol :  8 commits

• Définition : Compte, pour chaque fichier du dépôt, le nombre de fois qu’il a été modifié (ajout, suppression ou changement de contenu).

• Pourquoi ? Identifie les « points chauds » du code : fichiers fréquemment modifiés qui méritent une attention particulière (refactoring, tests). En TD, repère le fichier sur lequel les étudiants butent ou concentrent leur travail.

• Comment c’est calculé : Pour chaque commit.modified_files, on récupère mod.new_path ou mod.old_path (le chemin de fichier) et on incrémente fichiers_modifies[fichier].

• Interprétation Fichier très modifié → candidate pour revue de code ou simplification. Fichier jamais modifié → peut être obsolète ou initial, à ignorer.

• Exemple : Fichiers critiqués (Top 5) :

src/main.py    : 12 modifications
README.md      :  8 modifications
utils/helpers  :  7 modifications

• Définition : Pour chaque paire de contributeurs, nombre de fichiers qu’ils ont tous deux modifiés (pas nécessairement au même commit).

• Mesure de collaboration : si Alice et Bob modifient souvent les mêmes fichiers, ils travaillent sur des sujets communs ou se répercutent mutuellement.

• Comment c’est calculé : On maintient auteur_fichiers[auteur] = ensemble des fichiers modifiés par cet auteur. À chaque modification d’un fichier f par auteur, pour chaque autre_auteur s’il existe dans auteur_fichiers avec f ∈ auteur_fichiers[autre_auteur], on incrémente co_modification[f][auteur] et symétriquement pour autre_auteur.

• Interprétation Une forte co-modification peut indiquer des merges fréquentes ou un couplage fort du code. À utiliser pour repérer des dépendances implicites ou des couples d’étudiants travaillant trop isolément sur leurs propres fichiers.

• Exemple Co-modifications : src/main.py :

Alice : 5 fois
Bob   : 5 fois

• Définition : elle mesure le nombre de chemins de contrôle indépendants dans un bloc de code. Plus ce score est élevé, plus le code est complexe et difficile à maintenir.

• Pourquoi ? Aide à cibler les fonctions ou classes trop complexes. Facilite la planification de refactorings. Signale un manque possible de tests unitaires (code compliqué non couvert).

• Comment c’est calculer : Pour chaque fichier (pas uniquement .py ! mais Radon ne parse que Python), on lit tout le contenu et on appelle radon.complexity.cc_visit(code). On somme les attributs .complexity de chaque bloc renvoyé. On trie ensuite tous les fichiers par score décroissant et on garde le Top 10.

• Interprétation

 Score ≤ 10 : relativement simple.
 Score 10–20 : modérément complexe.
 Score > 20 : très complexe, facteur de dette technique.

• Exemple Complexité cyclomatique (Top 3) :

 module/data_processing.py : 28
 module/api.py             : 19
 main.py                   : 12

• Définition

 `Lignes ajoutées (added_lines)`
 `Lignes supprimées (deleted_lines)`
 `Total = ajoutées + supprimées`
  `% contribution = (total auteur) / (sum des total de tous) × 100`

• Pourquoi : Complète le nombre de commits, car un commit minime peut ajouter 100 lignes, ou inversement. Indicateur plus fin de quantité de travail « effectif ». Permet un suivi pondéré pour attribuer les notes.

• Comment c’est calculé Dans la boucle for mod in commit.modified_files :

`a = getattr(mod, "added_lines", 0)`
`d = getattr(mod, "deleted_lines", 0)`
`lignes_ajoutees[auteur]   += a`
`lignes_supprimees[auteur] += d`

À la fin :

`total_lignes = sum(lignes_ajoutees.values()) + sum(lignes_supprimees.values())`
`percent[auteur] = round(100 * (ajouts + suppressions) / total_lignes, 2)`

• Interprétation Exemple :

Alice a 300 ajouts / 50 suppressions = 350 lignes.
Si le total du groupe est 1000 lignes, alors Alice contribue 35 % du code.

• Définition: c'est une courbe (date vs. nombre de commits) pour chaque contributeur.

• Pourquoi ? Visualiser le rythme de travail dans le temps. Détecter des « sprints » (pics d’activité) ou des périodes d’inactivité. Vérifier l’effet des deadlines (axe vertical à la deadline).

• Comment c’est calculé : Structure evolution_par_auteur[auteur][YYYY-MM-DD] += 1. À la fin, on trace pour chaque auteur une série temporelle avec matplotlib.

• Interprétation Si toute l’équipe commit en même temps → travail collaboratif synchronisé. Si un auteur commit en continu vs. un autre en bout de course → coaching nécessaire.

• Définition : c'est un indicateur booléen a_heure valant True si le dernier commit du samedi est réalisé avant la deadline du TD.

• Pourquoi ? Évaluer la ponctualité des étudiants. Automatiser la gestion des retards.

• Comment c’est calculé : Pour chaque commit du samedi, on récupère la date et heure (commit.author_date). On compare à la deadline fournie dans tds.json (par date ou globale) :

 `dt_limite = datetime.strptime(f"{YYYY-MM-DD} {HH:MM}", "%Y-%m-%d %H:%M")`

a_heure = (commit_date <= dt_limite)

• Interprétation

 `Case cochée ✅ → soumission à l’heure`
 `❌ → retard (impact sur note ou pénalité)`

> > Indicateur | Pourquoi / Utilité > -- | -- > > Branches | Nombre de branches → complexité de la workflow > > Pull requests | Total / ouvertes / fermées / mergées → collaboration GitHub > > Reviews | Nombre de code reviews → qualité et peer review > > Issues | Tickets ouverts/résolus → suivi des bugs > > CI/CD runs | Total, succès, échecs → robustesse du pipeline

• Comment : On utilise requests.get() sur les endpoints GitHub v3, avec pagination (per_page=100, page=). On agrège les réponses JSON pour extraire les compteurs.

• Notes : Nécessite un token GitHub pour éviter les limites rate limit (60 → 5000 requêtes/h). Peut être étendu (couverture de tests, artefacts, vulnérabilités)