Revue humaine
Pour chaque changement, demandez : à quel besoin répond-il, quel comportement modifie-t-il, et existe-t-il un mécanisme existant pour faire le travail ?
Les seules demandes de revue n'autorisent pas les modifications. Suivez les conventions du projet et la portée définie par l'utilisateur, y compris les limites de test et de publication.
Retracer le comportement
Comparez les anciens et nouveaux chemins d'exécution, y compris les appelants et les branches de contournement. Distinguez le passage d'un objet, le passage d'une fabrique, et l'invocation de celle-ci. Établissez qui possède l'état, quand il est chargé, et quelles opérations voient un remplacement.
Examinez les duplications apparentes avant de les supprimer. Quel changement antérieur a rendu cette opération nécessaire ? Une nouvelle implémentation peut avoir perdu une vérification implicite de démarrage ou un nettoyage. Vérifiez les branches avant d'affirmer qu'un travail se fait deux fois.
Vérifiez le moment des échecs, les tentatives, le nettoyage des ressources, et si la cause originale atteint l'utilisateur. Une erreur passant du démarrage à la configuration de connexion peut changer le comportement même si les deux chemins échouent finalement. Vérifiez les consommateurs avant de traiter un type d'exception interne comme une exigence de compatibilité.
Simplifier la couche responsable
Inspectez d'abord ce que le composant récepteur prend déjà en charge. Si son contrat est suffisant, corrigez ce que l'appelant fournit plutôt que d'ajouter une autre responsabilité au récepteur. Ne déplacez pas le travail dans un constructeur partagé uniquement pour rendre les appelants similaires.
Justifiez chaque opération, champ, branche ou abstraction ajouté(e) par la tâche en cours. Pour les suppressions, vérifiez les appelants dépendants et les garanties. Préférez un contrat existant compatible ; conservez les adaptateurs qui effectuent une conversion significative ou appliquent un contrat.
Suivez l'état et le travail sur l'ensemble du chemin affecté. Supprimer un cache ne corrige pas un état obsolète si un appelant capture la même valeur dans une fermeture. Inversement, un fournisseur dynamique et une solution de repli basée sur un fichier peuvent intentionnellement se charger à des moments différents. Les unifier peut introduire une régression.
Jugez la simplicité par les concepts, les propriétaires d'état, et l'indirection qu'un lecteur doit suivre. Un diff plus petit n'est pas toujours une conception plus claire. Évitez le formatage non lié et la préparation pour des tâches futures.
Tester l'exigence
Chaque test doit raconter un cas cohérent à travers son nom, ses entrées, ses actions et son résultat attendu. Ne conservez que la configuration et les assertions qui établissent ce cas. Plusieurs phases vont ensemble lorsque la garantie en a besoin, comme la récupération après un échec ; les cas non liés ne vont pas ensemble.
Conservez le plus petit ensemble qui distingue les comportements requis et les régressions. Les compteurs d'appels internes n'ont d'importance que lorsqu'ils expriment une exigence, comme charger une fois. Confirmez qu'un échec injecté s'est réellement produit : un délai d'attente ou un socket fermé seul peut réussir pour la mauvaise raison.
Ordonnez les tests par comportement lié afin que le lecteur conserve un contexte utile pour le suivant. Utilisez des noms concrets au lieu de commentaires explicatifs. Considérez un commentaire comme une incitation à améliorer d'abord le code ; conservez les raisons qui ne peuvent pas être exprimées clairement dans les noms ou la structure.
Avant d'ajouter un accessoire personnalisé, une attente, une assertion ou un assistant de ressources, cherchez un cadre existant ou une facilité de classe de base. Préférez un code simple. Partagez une configuration répétitive lorsqu'elle reste compréhensible, mais gardez les entrées et actions spécifiques au scénario visibles. Évitez les rappels, les drapeaux ou les assistants à usage général qui économisent des lignes en cachant le cas.
Synchronisez sur l'événement dont l'assertion a besoin, pas sur un délai ou un événement antérieur dans un autre thread. Préservez le nettoyage en cas d'échec. Lisez les tests finaux dans l'ordre sans le diff et vérifiez que leur objectif est clair sans la conversation.
Expliquer et livrer
Conservez les commentaires qui expliquent une raison non évidente et empêchent une simplification erronée plausible. Supprimez la narration d'opérations évidentes. Gardez les contrats API précis et les instructions utilisateur exploitables ; lisez les sections éditées sans le diff pour vérifier qu'elles se suffisent à elles-mêmes.
Considérez à la fois le diagnostic de l'utilisateur et votre première impression comme des hypothèses. Signalez les conclusions étayées avec un scénario déclencheur, une conséquence, une preuve et la correction la plus petite utile. Séparez les défauts des questions ouvertes et des améliorations optionnelles. Aucune conclusion est un résultat valide.
Pour une refonte substantielle, expliquez une exécution concrète, ce qui devient plus simple, et le coût comportemental ou de compatibilité. Résolvez les choix en dehors du périmètre convenu avec l'utilisateur ; continuez les corrections autorisées de routine sans autre approbation.
Après les corrections, lisez le flux complet affecté et le diff final. Rapportez les conclusions, les vérifications effectuées et les lacunes restantes, plutôt que de narrer une question pour chaque ligne.