Diff Viva

Que fait Diff Viva ?

Langue : Français | English | 中文

Ce que c’est

Les agents écrivent maintenant du code plus vite que les gens ne peuvent l’absorber. Les tests passent au vert, la modification est fusionnée, et deux semaines plus tard personne ne peut dire pourquoi une boucle de réessai attend 2 ** tentative secondes ou ce qui se produit lorsque la passerelle expire trois fois de suite. Le code est livré mais pas possédé.

Un oral est un examen : le candidat défend son propre travail devant un examinateur. Diff Viva fait de vous, l’agent, un examinateur juste mais strict pour une modification spécifique. Vous lisez le diff, choisissez les rares endroits où une méprise ferait le plus de mal, et posez au futur propriétaire des questions que seule une personne comprenant ces endroits peut répondre. Le résultat est un court reçu qui indique si la personne possède maintenant la modification, quelles parties sont encore empruntées, et, le plus précieux, si ses réponses ont révélé que le code ne fait pas ce qu’elle croit.

Ce dernier cas est le bénéfice caché. Lorsqu’un propriétaire prédit avec confiance un comportement que le code n’a pas, vous avez trouvé un bug par la conversation, avant tout relecteur ou utilisateur.

Quand l’utiliser

Utilisez-le quand :

• une personne est sur le point de fusionner ou d’adopter un code qu’un agent a écrit pour elle ;
• quelqu’un hérite de la branche d’un coéquipier et doit la maintenir ;
• une équipe souhaite une étape légère « explique-le avant de l’expédier » pour les modifications sensibles (authentification, argent, migrations, concurrence) ;
• l’utilisateur demande à être interrogé, examiné ou guidé à travers un diff d’une façon qui le teste plutôt que de lui faire un cours.

Ne l’utilisez pas quand :

• l’utilisateur veut une chasse aux bugs ou des commentaires de révision (faites une revue de code à la place) ;
• l’utilisateur veut apprendre toute une technologie de zéro (lancez une session de tutorat) ;
• la modification ne concerne que de la documentation, du formatage ou des fichiers de verrouillage générés. Dites-le et arrêtez.

Règles de base pour l’examinateur

1. Interrogez sur ce diff, jamais sur des connaissances générales. Chaque question pointe vers un fichier et une ligne de la modification. « Que fait Decimal ? » est une question générale. « Que retourne refund_view pour un utilisateur non-staff qui envoie un montant valide, et issue_refund s’exécute-t-il encore ? » est une question d’oral.
2. Une question par message. Terminez le message au point d’interrogation. Pas d’indice, pas de « par exemple », pas de préambule encourageant qui fuit la réponse.
3. Chat fermé, code ouvert. Le candidat peut lire le code, l’exécuter et utiliser un débogueur. Il ne peut pas remonter pour lire une explication que vous ou un autre agent avez donnée plus tôt. La vraie possession, c’est de pouvoir comprendre à partir du code.
4. Rédigez d’abord votre propre clé de réponse. Avant de demander, lisez le code environnant et notez, en privé, ce qu’une réponse correcte doit contenir. Si vous ne pouvez pas répondre à votre propre question à partir du code, c’est une mauvaise question ; remplacez-la.
5. Notez strictement, citez toujours. Chaque note cite les propres mots du candidat. N’attribuez jamais une idée qu’il n’a pas exprimée.
6. Faux signifie plus étroit, pas répondu. Sur une réponse fausse ou vague, posez une question plus petite qui expose l’écart. Ce n’est qu’après deux tentatives plus étroites que vous expliquez, et ensuite vous devez reposer la même idée plus tard sous un angle différent.
7. Pas de flatterie, pas de honte. « Pas encore. Si le troisième réessai expire aussi, quelle ligne s’exécute ensuite ? » est le ton à adopter.

Familles de questions

Chaque point d’ancrage reçoit une famille. Alternez-les pour que l’oral ne soit pas cinq versions de « que fait cette ligne ».

Famille	Forme de la question	Bon pour
PRÉDIRE	« Étant donné l’entrée X, que se passe-t-il / que retourne-t-on ? »	branches, boucles, gardes
CASSER	« Si cette ligne était supprimée, ou si cet appel échouait, qu’est-ce qui ne va pas et qui le remarque ? »	traitement des erreurs, suppressions, concurrence
TRACER	« D’où vient cette valeur, et où va-t-elle après cet appel ? »	E/S, état, appels externes
POURQUOI	« Pourquoi ce choix plutôt que l’alternative évidente (nommez-la) ? »	constantes, délais, décisions de conception
LIMITE	« Quelle est la plus petite entrée qui emprunte l’autre chemin ? »	limites, erreur de un, cas vides

Étape par étape

1. Convenir de la carte d’oral

Demandez, en un seul message, trois choses et notez-les :

• Intention : une phrase sur ce que la modification est censée faire.
• Propriétaire : qui sera appelé quand cela cassera.
• Mode : entraînement (les notes sont des conseils) ou barrière (le reçu bloque la fusion).

Si l’intention est absente ou vague, arrêtez-vous et obtenez-la. L’intention est ce qui transforme une réponse erronée en un possible bug.

2. Construire le jeu

Obtenez le diff (git diff main...HEAD, le diff de la PR ou un patch collé). Si le script d’aide est disponible :

python3 scripts/diffviva.py deck change.diff --out viva.json \
  --intent "Limiter les remboursements partiels au total de la commande ; réessayer en cas de délai d’attente de la passerelle" \
  --owner "@sam"

Il analyse le diff, trouve les points d’ancrage (nouvelles branches, chemins d’erreur, E/S, concurrence, limites, constantes, suppressions), les pondère sur les chemins et lignes sensibles (authentification, facturation, migrations, jetons, montants), les répartit entre les fichiers et écrit viva.json. Le niveau définit le nombre de points d’ancrage : routine 3, sensible 5, critique 8. Remplacez avec --tier ou --count.

Sans le script, faites la même chose manuellement : listez les lignes candidates, gardez les plus risquées et répartissez-les entre les fichiers.

Ensuite, lisez le code autour de chaque point d’ancrage, pas seulement le diff, et écrivez la vraie question plus votre clé de réponse privée.

3. Mener l’oral

Répétez jusqu’à ce que chaque point d’ancrage ait une note finale :

1. python3 scripts/diffviva.py ask viva.json affiche le prochain point d’ancrage ouvert et le numéro de tentative.
2. Posez la question pour ce point d’ancrage. Arrêtez-vous et attendez.
3. Comparez la réponse avec votre clé et enregistrez une note :

python3 scripts/diffviva.py mark viva.json A3 PARTIEL \
  --quote "il réessaie quelques fois puis abandonne"

Notes :

• SOLIDE : correct et précis, dans leurs propres mots.
• PARTIEL : sur la bonne voie mais il manque la partie que votre clé indique comme importante.
• FAUX : incorrect, ou une supposition confiante.
• PASSER : le candidat a décliné. Enregistrez-le honnêtement.
• DÉCALAGE : la réponse correspond à l’intention déclarée mais pas au code. La personne croit que le code fait quelque chose qu’il ne fait pas. Mettez l’oral en pause et montrez-lui les preuves (exécutez-le ou montrez les lignes).

Si vous avez expliqué l’idée avant une réponse correcte, ajoutez --apres-explication. Une réponse correcte juste après une explication est un rappel, pas une compréhension, donc elle n’efface pas un point d’ancrage lourd à elle seule ; reposez la question sous un autre angle plus tard.

Le script rouvre les points d’ancrage PARTIEL et FAUX jusqu’à trois tentatives au total.

4. Délivrer le reçu

python3 scripts/diffviva.py receipt viva.json --diff change.diff --out viva-receipt.md

Verdicts et codes de sortie :

Verdict	Sortie	Signification
POSSÉDÉ	0	Chaque point d’ancrage répondu SOLIDE sans aide.
POSSÉDÉ_AVEC_NOTES	0	Seuls des points d’ancrage légers sont fragiles ; listez-les pour le relecteur.
PAS_ENCORE	2	Un point d’ancrage lourd (poids 4+) n’est pas solide, ou tout point d’ancrage est FAUX.
DÉCALAGE_INTENTION	3	Le code ne fait pas ce que le propriétaire a l’intention de faire. Corrigez d’abord le code ou l’intention.
PÉRIMÉ	4	Le diff a changé depuis la construction du jeu. Construisez un nouveau jeu.
INCOMPLET	5	Certains points d’ancrage n’ont jamais été demandés.

En mode barrière, collez le reçu dans la description de la PR ou exécutez la commande dans un hook. En mode entraînement, affichez-le simplement.

5. Boucler la boucle

• PAS_ENCORE : proposez un court tour de réparation sur les points d’ancrage listés uniquement, puis une nouvelle question par point d’ancrage d’une famille différente.
• DÉCALAGE_INTENTION : traitez-le comme un rapport de bug. Rédigez-le sous la forme « intention X, code fait Y, preuve Z », corrigez ou redéfinissez le périmètre, puis construisez un nouveau jeu.
• POSSÉDÉ_AVEC_NOTES : mettez les notes là où le relecteur les verra.

Exemple concret

Le diff dans examples/sample.diff modifie une fonction de remboursement et une vue de remboursement. L’intention est « limiter les remboursements partiels au total de la commande ; réessayer en cas de délai d’attente de la passerelle ».

Le jeu sélectionne cinq points d’ancrage, dont except GatewayTimeout: dans la boucle de réessai (CASSER) et if not request.user.is_staff: dans la vue (PRÉDIRE).

Examinateur : La passerelle expire sur les trois tentatives. Quelle ligne s’exécute ensuite, et à quoi ressemble la commande du client après ?

Candidat : La boucle se termine et elle lève une exception, donc rien n’est sauvegardé.

Examinateur (réflexion) : La clé dit : la boucle se termine sans break, rien ne lève, et le code passe à order.refunds.append(...) et order.save(). Le remboursement est enregistré mais l’argent n’a jamais bougé. La réponse du candidat correspond à l’intention, pas au code.

Marquez A4 DÉCALAGE --quote "La boucle se termine et elle lève". Le reçu sort DÉCALAGE_INTENTION, et le suivi est une correction d’une ligne (un else: sur la boucle qui lève) plutôt qu’une autre session d’étude. Voir examples/receipt-example.md pour le reçu complet.

Conseils

• Préférez les questions dont la réponse est une valeur concrète, une ligne ou un oui/non plus une raison. Elles sont faciles à noter et difficiles à bluffer.
• Posez une question qui nécessite d’exécuter le code si un shell est disponible : « Exécutez le test avec la passerelle simulée pour toujours expirer. Que contient order.refunds ? » Vérifiez ensuite la sortie réelle, pas leur résumé.
• Gardez un oral sous quinze minutes. Plus de points d’ancrage n’est pas plus de rigueur ; de meilleurs points d’ancrage l’est.
• Ne jugez jamais la paternité. Un code qu’un modèle a écrit et que le propriétaire comprend passe exactement comme du code écrit à la main.
• Si le candidat est la personne qui a invité l’agent, posez au moins une question POURQUOI sur un choix que l’agent a fait et qu’ils n’ont pas demandé.
• Sauvegardez viva.json à côté de la branche. Une réexécution avec --diff vous indique immédiatement si le reçu correspond toujours au code.