Présentation
Dans ce tutoriel, vous allez travailler sur un backlog de Code Quality résultats sur votre branche par défaut, hiérarchiser par risque, résoudre les résultats les plus impactants et communiquer le résultat aux parties prenantes. Vous apprendrez ce qui suit :
- Comment lire le tableau de bord et comprendre ce que signifient vos scores.
- Comment hiérarchiser la correction et décider s’il faut appliquer un correctif automatique, déléguer à Agent cloud Copilotou ignorer une recherche.
- Comment communiquer l’impact du travail de correction.
- Quelles mesures supplémentaires vous pouvez prendre pour empêcher le backlog de croître à nouveau.
Il s’agit d’un parcours guidé, qui privilégie la compréhension plutôt que la rapidité. Pour les étapes de base permettant de créer un correctif automatique ou de rejeter un résultat, consultez le guide pratique associé : Correction des problèmes de qualité du code dans le backlog de votre dépôt.
Avant de commencer
- Code Quality est activé sur un référentiel que vous possédez ou gérez. Consultez « Activation de GitHub Code Quality ».
- Si vous avez activé Code Quality récemment, patientez quelques minutes pour que l’analyse initiale CodeQL de votre branche par défaut se termine.
Tout au long de ce tutoriel, nous allons utiliser un exemple en cours d’exécution : un référentiel dont le tableau de bord affiche actuellement des scores de « Fiabilité : Médiocre » et « Maintenance : Juste » pour la qualité du code.
Étape 1 : Évaluer votre score actuel
- Accédez à l’onglet Security and quality de votre référentiel.
- Cliquez pour développer Qualité du code, puis cliquez sur Résultats standard.
Ici, vous verrez des scores pour la fiabilité et la facilité de maintenance.
Ces scores sont calculés à partir des résultats de votre branche par défaut :
| Metric | Definition | Exemples de résultats |
|---|---|---|
| Fiabilité | Évaluez si le code effectue sa fonction prévue correctement, de manière prévisible et cohérente. Le code fiable est exempt de bogues, gère les erreurs en toute sécurité et fonctionne comme prévu dans des conditions normales et de cas de périphérie. | Problèmes liés aux performances, à la concurrence, à la gestion des erreurs, à la correction |
| Maintenabilité | Évaluez la facilité de compréhension, de modification et d’extension du code au fil du temps. Le code gérable suit les meilleures pratiques, évite la complexité inutile et est organisé pour faciliter les modifications et la collaboration futures. | Code inutilisé ou mort, lisibilité, complexité, conventions de nommage incohérentes, mauvaise séparation des préoccupations |
Chaque score est déterminé par le niveau de gravité le plus élevé du constat encore présent pour cette métrique. Pour améliorer un score, vous devez résoudre chaque résultat du niveau de gravité le plus élevé actuel.
Dans notre exemple, la fiabilité est « Médiocre », car il existe toujours des résultats au niveau de l’erreur affectant la fiabilité. Les avertissements et les notes valent la peine d’être traités, mais jusqu’à ce que les erreurs soient effacées, elles ne peuvent pas déplacer le score.
Étape 2 : Lire la liste par règle et se concentrer sur les résultats les plus impactants
Dans la Résultats standard vue, les résultats sont regroupés par règle. Cela est utile pour comprendre, car une règle unique avec de nombreux résultats peut refléter une habitude de codage répétée. Une fois que vous avez compris une occurrence, il peut être plus facile de comprendre les corrections automatiques proposées pour l’ensemble des occurrences, ce qui rend la correction plus rapide et l’examen en bloc plus facile.
En outre, recherchez les règles qui compléteraient un niveau de gravité pour l’un de vos scores : si le fait de lever une règle supprime la dernière « Erreur » restante affectant la fiabilité, votre score augmente immédiatement.
Dans notre exemple, une règle — « Propriété remplacée » — représente 40 des 128 résultats, et les 40 sont de niveau Erreur. Le corriger supprimerait tous les problèmes de niveau Erreur affectant la fiabilité, ce qui ferait passer notre score à la tranche supérieure.
Étape 3 : Résoudre les résultats
Une fois que vous avez choisi une règle, décidez comment gérer chaque recherche :
| Assessment | Action recommandée | Notes |
|---|---|---|
| La conclusion est légitime. | Cliquez sur Générer un correctif et ouvrez une pull request | Cliquer sur Générer le correctif consomme AI credits. Vous pouvez ajouter plusieurs corrections automatiques à la même branche afin de regrouper le travail de remédiation dans une seule pull request. |
| Le résultat ne s’applique pas. Par exemple, il se trouve dans du code hérité, un modèle intentionnel ou un faux positif | Cliquez sur Ignorer. | La recherche est considérée comme résolue et supprimée de la liste des résultats ouverts. |
Dans notre exemple, nous générons des corrections automatiques pour les 40 signalements « propriété écrasée » et ouvrons une pull request. Étant donné qu’ils partagent un modèle unique, les correctifs sont presque identiques. Nous fusionnons la pull request une fois que les vérifications CI ont réussi.
Étape 4 : Communiquer l’impact
Une fois votre correctif fusionné, revenez à la vue « Résultats standard » et capturez :
- Score qui a changé. Par exemple, Fiabilité : Faible → Moyenne.
- L’exigence qui l’a déverrouillée. Par exemple, tous les problèmes de niveau erreur affectant la fiabilité sont désormais résolus.
- Réduction des résultats ouverts. Par exemple, de 128 ouvert à 88.
Dans notre exemple, la suppression de la règle « Propriété écrasée » fait passer la fiabilité de Médiocre à Passable — la première amélioration de score que l’équipe peut mettre en avant.
Comment cela s’inscrit dans le reste de votre qualité de code
Chaque résultat que vous avez résolu aujourd’hui peut réapparaître demain si de nouvelles pull requests introduisent le même type de problème. Pour empêcher le backlog de se régénérer :
- Définissez un seuil de fusion sur votre branche par défaut pour bloquer les pull requests qui introduisent de nouveaux problèmes de qualité du code. Consultez « Définition des seuils de qualité du code pour les pull requests ».
- Corrigez les problèmes dans la pull request dès qu’ils apparaissent. Consultez « Empêcher les problèmes de qualité du code d’atteindre votre branche par défaut ».
Résolution des problèmes
- Les scores n’ont pas été déplacés après la fusion des correctifs. Au moins une recherche au niveau de gravité le plus élevé actuel pour cette métrique est toujours ouverte.
- L’analyse n’a pas été réexécutée. Code Quality les analyses s’exécutent automatiquement après chaque envoi (push) vers la branche par défaut. Attendez quelques minutes que le flux de travail se termine.
Conclusion
Dans ce tutoriel, vous avez évalué les scores de qualité de votre dépôt, priorisé les tâches du backlog selon leur gravité et la règle concernée, corrigé les problèmes détectés grâce aux corrections automatiques et présenté le résultat sous la forme d’une évolution du score.
Étapes suivantes
- Réduisez davantage la dette technique en corrigeant les résultats dans les fichiers récemment modifiés. Consultez « Correction des résultats de la qualité du code dans les fichiers récemment fusionnés ».