Explorateur de PR + quiz de compréhension

Que fait Explorateur de PR + quiz de compréhension ?

Le codage assisté par IA permet d'approuver facilement du code que l'on n'a jamais vraiment compris. Cette compétence explique un changement au niveau nécessaire pour un réviseur, puis vérifie la compréhension avec quelques questions ciblées — pour que « LGTM » ait un sens.

1. Récupérer le changement

Choisissez celui qui convient :

gh pr view <num> --json title,body,baseRefName,headRefName,files   # PR GitHub
gh pr diff <num>
git diff <base>...<head>                                            # branche
git show <sha>                                                     # commit unique

Lisez la description de la PR et le problème lié s'il y en a un. Lisez ensuite le code environnant des fonctions modifiées (appelants, appelés, tests) — un diff seul cache le contexte important.

2. Expliquer — dans cet ordre

1. Résumé d'un paragraphe : quel changement de comportement pour un utilisateur ou un appelant. Pas une liste de fichiers.
2. Pourquoi : le problème résolu, à partir de la description/du problème/des messages de commit. Si la raison n'est mentionnée nulle part, dites-le — c'est une constatation de révision.
3. Diagramme : un sequenceDiagram ou flowchart Mermaid du nouveau flux, en mettant en évidence ce qui est nouveau/changé (utilisez une note ou la classe :::changed). Limitez-le à ~15 nœuds ; diagrammez le chemin principal, pas tout.
4. Présentation par concept, pas par fichier : regroupez les parties liées (« la logique de nouvelle tentative », « le nouveau drapeau de configuration »). Pour chacune : ce qu'elle fait, et tout ce qui n'est pas évident (concurrence, gestion des erreurs, cas limites, performances).
5. Notes de risque : les éléments qu'un réviseur doit examiner le plus attentivement — interfaces publiques modifiées, migrations, tests supprimés, chemins d'erreur ignorés, code sensible à la sécurité, tests manquants pour les nouvelles branches. Soyez précis avec fichier:ligne.

3. Quiz

Posez 3 à 5 questions, une à la fois, en attendant la réponse avant la suivante. Les bonnes questions nécessitent de la compréhension, pas de la mémoire :

• « Que se passe-t-il maintenant si <dépendance> expire pendant <opération> ? »
• « Quel appelant existant est affecté par le changement de signature, et comment ? »
• « Pourquoi <ligne> doit-elle venir avant <ligne> ? »
• « Si on annule ce changement après que la migration a été exécutée, qu'est-ce qui se casse ? »

Évitez les détails superficiels (« comment s'appelle la nouvelle fonction ? »). Mélangez : au moins une sur le comportement en cas d'échec/limite, une sur la raison d'un choix de conception.

Après chaque réponse : dites si elle est correcte, et donnez l'explication correcte en 1 à 3 phrases avec une référence de code. Si le réviseur a tort sur un point important, suggérez quelle partie du diff relire.

4. Conclusion

Note (ex. 4/5) et un avis court : « prêt à examiner » ou « relire X avant d'approuver ». Proposez de rédiger des commentaires de révision pour les risques identifiés.

Adapter à la demande

Le flux complet (résumé → pourquoi → diagramme → présentation → risques → quiz) est le comportement par défaut pour « explique-moi ça » ou « aide-moi à réviser ». Lorsque l'utilisateur restreint la demande, respectez-la :

• « pas de quiz » / « saute le quiz » : étapes 1–2 sans étape 3.
• « juste le résumé et les risques » : le résumé d'un paragraphe et les notes de risque, rien d'autre : pas de diagramme, pas de présentation. Proposez le reste en une ligne de conclusion.
• « juste le diagramme » : le diagramme plus une légende de deux phrases.

Le premier risque listé devrait être celui qui change le comportement pour les utilisateurs ou l'argent (comme une facturation erronée silencieuse), pas le plus intéressant techniquement.