- Description
- Des tubes à essai
- Source
- B.Lachner · page d’origine
- Licence
- CC0 Domaine public
Qualité du code
Ce thème mesure la lisibilité et la fiabilité du code au moment où on le modifie : défauts attrapés avant la fusion, conventions appliquées sans débat, revues qui transmettent autant…
En bref
Ce thème mesure la lisibilité et la fiabilité du code au moment où on le modifie : défauts attrapés avant la fusion, conventions appliquées sans débat, revues qui transmettent autant qu'elles contrôlent. Il ne mesure pas le « nombre de règles » mais le taux de défauts qui échappent et le temps de relecture d'un changement.
Niveau : 🟢→🔴 · Code thème : COD (matrice DL)
Pourquoi ce thème#
Le code se lit bien plus souvent qu'il ne s'écrit. Un code illisible n'est pas seulement désagréable : il multiplie le temps de correction, fait fuir les relecteurs (les revues deviennent des validations de principe) et laisse passer des défauts que des outils attraperaient pour rien. À l'inverse, l'excès de règles cosmétiques crée du bruit : si l'analyse statique remonte 3 000 avertissements, plus personne n'en lit un seul.
En SQL et en scripts d'automatisation, le piège est spécifique : requêtes d'un seul bloc de 600 lignes, jointures implicites, SELECT *, transformations de types silencieuses, scripts PowerShell sans gestion d'erreur. Les mêmes principes s'appliquent, avec des outils différents (analyse T-SQL, PSScriptAnalyzer).
Ce que mesure le thème#
- Axe : de « chacun son style » à « la qualité est une propriété vérifiée à chaque changement ».
- Indicateur clé : taux d'échappement (part des défauts de code découverts après fusion) ; âge médian d'une demande de fusion (de l'ouverture à la fusion).
- Unité : % de défauts échappés ; heures de latence de revue ; dette signalée par l'analyse statique par millier de lignes.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Individuel | Le code marche, la qualité dépend de la personne qui l'écrit. | Aucun contrôle partagé ; revue exceptionnelle |
| 2 | Convenu | Le code d'un collègue est lisible dans les mêmes conventions que le tien. | Guide de style ; revue sur > 50 % des changements |
| 3 | Vérifié | Un défaut courant est signalé avant même que quelqu'un relise. | Analyse statique en CI ; latence de revue < 1 jour ouvré |
| 4 | Maîtrisé | La qualité d'un changement se mesure et se compare dans le temps ; le code nouveau ne dégrade jamais l'existant. | « Clean as you code » : 0 défaut bloquant nouveau ; échappement < 10 % |
| 5 | Exemplaire | Le code se corrige et se refactorise sans crainte et sans coordination ; la qualité attire les contributions. | Échappement < 3 % ; refactoring continu mesuré |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-COD-1.1 | Le code compile/s'exécute depuis une source versionnée | Reconstruction depuis un clone neuf |
| DL-COD-1.2 | Les noms de variables, objets SQL et scripts suivent un usage minimal commun | Revue d'un échantillon de 20 objets |
| DL-COD-1.3 | Les erreurs connues sont journalisées, pas avalées | Pas de catch vide ni de ON ERROR muet dans l'échantillon |
| DL-COD-2.1 | Un guide de style (nommage, schéma, indentation) est écrit et accessible | Document daté < 12 mois |
| DL-COD-2.2 | Toute modification passe par une revue par un tiers avant fusion | ≥ 90 % des changements fusionnés ont un relecteur |
| DL-COD-2.3 | Une liste de contrôle de revue existe (sécurité, erreurs, nommage) | Liste présente dans le modèle de demande |
| DL-COD-2.4 | Les formats (indentation, fin de ligne, encodage) sont fixés dans un fichier de configuration | Configuration versionnée |
| DL-COD-3.1 | Un formateur automatique est appliqué en pré-commit ou en CI | Une dérive de style fait échouer la CI |
| DL-COD-3.2 | Une analyse statique (linter, analyse T-SQL, PSScriptAnalyzer) s'exécute à chaque demande de fusion | Rapport joint à chaque PR |
| DL-COD-3.3 | La latence médiane de revue est < 1 jour ouvré | Mesure sur 3 mois |
| DL-COD-3.4 | Les secrets, mots de passe ou chaînes de connexion sont détectés avant fusion | Détecteur actif, test volontaire détecté |
| DL-COD-4.1 | Les seuils de qualité s'appliquent au code nouveau (complexité, duplication, couverture) et bloquent la fusion | Un dépassement volontaire est refusé |
| DL-COD-4.2 | Le taux de défauts échappés est mesuré et suivi par trimestre | Tendance sur 4 trimestres |
| DL-COD-4.3 | Les revues sont de taille bornée (≈ ≤ 400 lignes modifiées) | Distribution de taille des PR |
| DL-COD-4.4 | Les décisions de revue récurrentes deviennent des règles automatiques | Liste des règles issues de revues |
| DL-COD-5.1 | La complexité cyclomatique et le couplage du cœur baissent ou restent stables sur 12 mois | Courbe sur 12 mois |
| DL-COD-5.2 | Le refactoring est un acte courant, protégé par des tests, sans « chantier dédié » | ≥ 1 refactoring par itération tracé |
| DL-COD-5.3 | Un nouveau contributeur obtient une revue utile en moins de 4 heures | Mesure de la première réponse |
| DL-COD-5.4 | Le code exemplaire est identifié et sert de référence (modèles, exemples) | Dépôt de modèles utilisé en pratique |
Lecture détaillée par niveau#
🟢 Niveau 1 — Individuel#
- Signes : trois styles dans le même dépôt ; scripts de 500 lignes sans fonctions ; erreurs ignorées.
- Gain : rapidité d'écriture sur un périmètre qu'on est seul à toucher.
- Ne garantit pas : qu'un tiers puisse reprendre ; qu'un défaut soit vu avant la production.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Convenu#
- Signes : guide de style, revue par un tiers, liste de contrôle de revue. Les débats de style cessent d'occuper les revues.
- Gain : une partie des défauts est détectée par un second regard ; le savoir circule.
- Ne garantit pas : la constance — la revue dépend de l'attention humaine et se dégrade sous la pression.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Vérifié#
- Signes : la machine fait ce qui est mécanique (formatage, détection de secrets, analyse statique), l'humain regarde le fond. Le temps de revue diminue.
- Gain : moins de défauts triviaux ; revues centrées sur la conception.
- Ne garantit pas : la qualité de la conception, ni la maîtrise de l'existant.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Maîtrisé#
- Signes : la barre s'applique au code nouveau (« propre en avançant »), ce qui évite le gouffre du « tout nettoyer d'abord ». Les défauts échappés sont analysés pour améliorer règles et tests.
- Gain : l'existant cesse de se dégrader sans bloquer la livraison.
- Ne garantit pas : la correction fonctionnelle — voir 03 Tests.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Exemplaire#
- Signes : le refactoring est quotidien, sécurisé par les tests ; le code sert de documentation ; les contributions externes à l'équipe sont faciles.
- Gain : la capacité à changer vite sans casser, durablement.
- Ne garantit pas : l'absence de dette — la dette de conception demeure (09).
- Difficulté : 5/5 · Effort : 4/5.
Atteinte partielle et notation#
Appliquez la règle de notation. Repères :
- 0,5 sur DL-COD-3.2 : l'analyse statique tourne mais seulement sur un des deux dépôts (ex. le C# mais pas les scripts SQL).
- 0,5 sur DL-COD-4.1 : seuils actifs sur le code nouveau mais non bloquants.
- Un 5 partiel : refactoring courant et revue rapide, mais pas encore de mesure de tendance sur 12 mois.
Avertissements ignorés. Symptôme : des milliers d'alertes, jamais lues. Cause : seuil absent, règles non triées. Remède : désactiver ce qui n'est pas actionnable, bloquer sur le code nouveau seulement.
Passer au niveau suivant#
Moyens possibles (facultatifs) — le résultat visé reste celui de la promesse.
- 1 → 2 : un fichier de conventions (une page) et la règle « personne ne fusionne seul ».
- 2 → 3 : formateur et linter en CI, détecteur de secrets, revue limitée en taille.
- 3 → 4 : seuils sur le code nouveau, analyse des défauts échappés, règles issues de revues.
- 4 → 5 : budget de refactoring dans chaque itération, tests de caractérisation sur l'existant.
Une demande de fusion de 150 lignes est relue en 15 minutes ; une de 1 500 lignes est approuvée « sans regarder ». Bornez la taille, pas la durée.
Un objectif de « zéro alerte » pousse à supprimer les règles. Un objectif de couverture pousse à des tests creux. Suivez la tendance et le taux d'échappement, jamais un seuil isolé.
Les assistants de code accélèrent la rédaction et proposent des revues de premier niveau (gain 4/5, risque 3/5 : code plausible mais faux, dépendances inventées). Garde-fou : la CI applique les mêmes barrières au code généré qu'au code humain ; la responsabilité reste au relecteur.
Un script SQL de consolidation de 900 lignes est découpé en trois procédures nommées par rôle. L'analyse statique repère deux SELECT * et une conversion implicite ; la revue ne porte plus que sur la logique de jointure.
Voir aussi#
- Voisins : 01 Architecture · 03 Tests · 05 CI · 09 Dette technique · 12 Expérience développeur.
- Autres matrices : BI — mesures et calculs DAX · Projet — qualité et recette · Data — qualité des données.
- Pratique : CI/CD · Git en profondeur · Azure DevOps / TFS · pièges et bonnes pratiques.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
