Sujet : code-review
-
Quelles métriques de revue de code prédisent les défauts non détectés sans se prêter à la manipulation ?
Question ouverte : le délai de revue, la densité des commentaires et la taille des modifications sont faciles à mesurer, mais lesquels prédisent réellement les défauts découverts après fusion, et lesquels cessent d’être utiles dès que les équipes cherchent à les optimiser ?
-
Liste de contrôle de revue de confidentialité pour une fonctionnalité
Dix questions auxquelles une personne chargée de la revue répond avant la mise en production d'une fonctionnalité : inventaire des nouvelles données personnelles, décisions de minimisation, tâche de rétention, accès et journalisation des accès, couverture de l'export et de la suppression, finalités de préférence, flux vers des tiers, une brève passe LINDDUN, données de test, et un résultat consigné ; uniquement des propriétés d'ingénierie, sans évaluation juridique.
-
Le formatage et le linting automatisés comme contrat d'équipe
Déléguer la mise en forme à un formateur et les vérifications mécaniques à un linter retire les débats de style de la revue ; EditorConfig, PEP 8 et des outils tels que Ruff montrent comment ce contrat peut être encodé dans le dépôt.
-
Décrire un changement pour que les relecteurs puissent le relire
Une description de changement énonce le problème, l'approche et ses alternatives, la façon dont il a été testé et ce que les relecteurs doivent examiner ; elle renvoie au ticket et liste les risques et les suites à donner, afin que la relecture commence par la compréhension plutôt que par l'archéologie.
-
Réviser du code écrit par un agent d'IA
Un protocole de révision proposé pour les modifications générées : comparer le diff avec la demande, confirmer l'existence de chaque API et dépendance, vérifier les affirmations sur les tests en les exécutant et en les mettant en échec, lire les tests avant l'implémentation, traquer les erreurs avalées, et consigner ce qui a été vérifié.
-
Revue de code : une checklist pour les relecteurs
Une checklist compacte pour les revues de code : comprendre l'objectif, le design avant le style, la justesse et les cas limites, les tests, la lisibilité ; un retour dans la journée ouvrée et une approbation dès que le changement améliore le code dans son ensemble.
-
Reconnaître les code smells avant de refactoriser
Les code smells sont des symptômes de surface (méthodes longues, grandes classes, feature envy, shotgun surgery, primitive obsession) qui suggèrent un problème de conception plus profond ; les nommer donne un vocabulaire pour la revue et un déclencheur pour le refactoring.
-
Écrire des commentaires que le code ne peut pas dire : raisons, contraintes, pièges
Un commentaire vaut la peine lorsqu'il dit quelque chose que le code ne dit pas : la raison d'une décision surprenante, la contrainte externe, le piège pour la prochaine personne. Il ne répète pas ce que le code dit déjà ; PEP 8 établit qu'un commentaire qui contredit le code est pire que l'absence de commentaire. Avant de commenter, il convient de vérifier si un meilleur nom ou un test ne rendrait pas le commentaire superflu.
-
Texte invisible et réordonné : contrôles bidirectionnels, caractères de balisage et caractères ambigus dans le code et les prompts
Unicode permet à un texte de contenir des caractères qu'une personne relectrice ne peut pas voir, ou qui réordonnent ce qui s'affiche. Les contrôles bidirectionnels peuvent faire lire le code source différemment de la façon dont il compile, les caractères de balisage (tag characters) peuvent cacher des instructions qu'un modèle reçoit tout de même, et les caractères ambigus (confusables) imitent des identifiants. La détection consiste à examiner les points de code, pas le rendu.
-
Mener une revue de code qui améliore le code
Une procédure de relecteur dérivée des pratiques d'ingénierie de Google : juger si le changement améliore la santé globale du code, examiner la conception avant le style, et garder un délai de traitement inférieur à un jour ouvré.
-
Mener une revue de conception : période de commentaires, décideur nommé et décision consignée
Une revue de proposition a besoin d'une période de commentaires bornée, d'une personne ou d'un groupe nommé qui décide, d'une décision écrite (acceptation, rejet, report) avec ses raisons, et d'une règle de réouverture ; le processus RFC de Rust et le processus PEP de Python montrent la forme, et cette méthodologie l'adapte à une seule équipe.
-
Exprimer un désaccord par écrit : défendre la position adverse sous sa meilleure forme, puis réfuter le point central
Un désaccord écrit capable de faire évoluer une décision reformule d'abord la position adverse sous sa forme la plus solide, désigne précisément ce qui est contesté, cite le passage erroné, apporte des preuves graduées et propose une alternative ; la hiérarchie du désaccord de Paul Graham classe les réponses depuis l'insulte jusqu'à la réfutation du point central.
-
Garder les commits de reformatage hors de git blame : -w et les fichiers ignore-revs
git blame -w ignore les espaces lors de la recherche de l'origine des lignes ; --ignore-rev et un fichier .git-blame-ignore-revs versionné permettent d'écarter des commits nommés, comme les reformatages massifs, afin que les lignes soient attribuées au dernier changement significatif qui les précède ; -M et -C suivent les lignes déplacées ou copiées. GitHub lit automatiquement ce même fichier.
-
Contredire par écrit sans blesser : citation, point central, alternative
Une objection écrite susceptible de faire évoluer une décision restitue d'abord la position adverse sous sa forme la plus forte, cite le passage contesté, s'attaque au point central plutôt qu'au ton ou à la personne, évalue honnêtement sa propre preuve, et propose une alternative. La hiérarchie du désaccord de Paul Graham et le guide de relecture de Google fournissent les repères.
-
Hiérarchiser l'attention de revue de code avec Jev sans noyer les bloqueurs dans une moyenne
Utiliser des dimensions de revue distinctes pour prioriser l'attention humaine, tout en conservant des contrôles obligatoires qu'un score pondéré ne doit jamais outrepasser.
-
Le refactoring par petites étapes vérifiées
Le refactoring change la structure interne, pas le comportement observable. Un refactoring nommé du catalogue après l'autre, des tests au vert après chaque étape, un retour en arrière plutôt qu'un débogage en avant au rouge, des changements de structure et de comportement dans des commits séparés – ainsi, le travail reste sûr et vérifiable en quelques minutes.
-
Les tests de snapshot et de fichier de référence, et comment les garder honnêtes
Un test de snapshot sérialise une sortie et la compare à une référence stockée ; il couvre tout et ne décrit rien. Garder les snapshots petits, normaliser les champs volatils, relire les diffs de snapshot comme du code et les mettre à jour de façon sélective, sous peine de les voir dégénérer en bruit approuvé.
-
Une liste de contrôle de revue de code axée sécurité pour les changements aux frontières de confiance
Une courte liste de questions qu'une relecture pose à tout changement touchant à la saisie, à l'authentification, à l'autorisation, à l'accès aux données, aux requêtes sortantes, aux fichiers, aux secrets ou aux dépendances : par où entrent les données non fiables, qui est autorisé à faire cela, qu'est-ce qui est interrogé, où cela envoie-t-il ou stocke-t-il, et qu'est-ce qui est journalisé. Appliquée uniquement aux changements touchant une frontière, afin de rester assez courte pour être réellement utilisée.
-
Le principe des quatre yeux au déploiement : imposer les validations techniquement
Aucune version n'atteint la production sans qu'une seconde personne l'ait vue et validée — et ce de telle sorte que ce soit l'outil qui l'impose, et non la discipline individuelle : branches protégées avec revue obligatoire, validation obligatoire pour l'environnement de production, aucun contournement pour les administrateurs, et une voie d'urgence journalisée plutôt qu'interdite.
-
Faire correspondre une affirmation de revue de code au comportement modifié précis qu'elle étaye
Construire une carte de revue compacte qui empêche des contrôles réussis mais sans rapport d'être utilisés comme preuve pour un comportement nouvellement modifié.
Lisible par machine : JSON