Revue Axée sur la Demande

Vue d'ensemble

En ingénierie, le point de départ en premiers principes est la demande (le besoin). Le plus grand gaspillage en revue est de fournir des suggestions de polissage de haute qualité pour quelque chose qui ne devrait pas exister. Commencez par auditer si la demande est réelle (archéologie des consommateurs) ; ne reviewez l'implémentation que de ce qui survit.

Classement ferme (les trois premières étapes de l'algorithme des cinq étapes de Musk) : remettre en question les exigences → supprimer → uniquement ensuite simplifier/optimiser. Inverser l'ordre = optimiser quelque chose qui ne devrait pas exister.

Archéologie des Consommateurs (flux de travail principal)

Pour chaque API / canal / paramètre / type / champ nouvellement ajouté :

Lister les consommateurs : tracer TOUS les sites d'appel réels entre les branches et les dépôts (git grep y compris les branches de fonctionnalités). Ne faites pas confiance à la description du PR.
Mesurer la consommation : pour chaque consommateur, vérifiez quelle partie de la valeur renvoyée / capacité il lit réellement. Nombre de consommateurs ≠ consommation ; un consommateur qui ne lit qu'un booléen consomme zéro d'une taxonomie d'erreurs. Consommation réelle = la taille réelle de la demande.
Juger la pseudo-demande — deux vérifications, toutes deux obligatoires :
- Consommation zéro → pseudo-demande ;
- Consommation non-zéro mais politique : cette dimension déplace-t-elle un jugement que le consommateur pourrait calculer en une ligne dans le contrat (par exemple, un paramètre expectedKind vs. « lire kind et comparer ») ? Les contrats portent des faits ; la politique se réinsère dans les consommateurs — supprimer même s'il y a de vrais lecteurs.
L'un ou l'autre → remettre en question toute la dimension au lieu de la polir.
Vérifier la capacité de même source : une API existante couvre-t-elle déjà ceci, y compris les relations de « projection stricte » (par exemple getFileSize ≡ getMetadata().size) ? Ne jamais ouvrir un second point d'entrée pour la même capacité.
Vérifier la responsabilité : la demande a-t-elle fui d'une autre couche (par exemple, un renderer interprétant les erreurs fs, une UI faisant de la validation métier) ? Les requêtes check-then-act devraient généralement devenir try-the-operation.

Après que chaque question élimine une couche, appliquez le review d'implémentation normal (validation, tests, types, docs) uniquement aux survivants.

Tableau de Rationalisation

Excuse	Réalité
« L'API est propre / les types sont élégants »	Une chose propre qui ne devrait pas exister ne devrait toujours pas exister. Remettre en question l'existence en premier.
« Elle a des consommateurs »	Compter n'est pas assez. Vérifier quels champs chaque consommateur lit — une dimension de consommation zéro est toujours une pseudo-demande.
« Ce paramètre/champ EST consommé »	Consommé ≠ devrait exister. Deuxième vérification : fait ou politique ? Une dimension qui déplace un jugement consommateur d'une ligne dans le contrat se réinsère, lecteurs ou non.
« Export inutilisé trouvé — ajouter un test pour la sécurité »	Les signaux de consommation zéro devraient déclencher des questions de demande, pas un backfill de test.
« Une contrainte technique le rend nécessaire »	Demander si la demande servie par cette contrainte est elle-même réelle. Les contraintes ne sont pas des axiomes.
« Le PR est additif, il ne casse rien »	L'additif est exactement comment les pseudo-demandes s'introduisent. Une nouvelle surface a besoin de PLUS de scrutin d'existence qu'une surface modifiée.
« On pourrait en avoir besoin plus tard / compatibilité avant »	Consommation zéro maintenant signifie pseudo-demande maintenant. L'ajouter quand un vrai consommateur apparaît.
« L'existence est l'affaire de l'auteur / de l'architecte »	Remettre en question la demande fait partie de la review. Réduire les questions d'existence à des points mineurs, c'est ne pas les poser.

Signaux d'Alerte — arrêter, revenir à l'étape 1

Vous avez écrit cinq commentaires au niveau implémentation sans lister les consommateurs
Votre rapport dit « spéculatif » / « pas de consommateurs pour le moment » / « inutilisé » mais conclut garder / noter / ajouter un test
Vous trouvez des raisons pour qu'une API existe au lieu de trouver ses consommateurs
Vous êtes sur le point de suggérer « ajouter un commentaire expliquant pourquoi c'est nécessaire » — d'abord confirmer que c'est nécessaire

Impact Réel

PR #15695 (2 nouveaux canaux IPC) : six agents de review au niveau implémentation ont produit 30+ commentaires de polissage, zéro remise en question de l'existence. Trois questions d'archéologie des consommateurs plus tard : un canal rejeté comme point d'entrée dupliqué, un paramètre supprimé, un canal classé comme dette à supprimer — invalidant la plupart des commentaires de polissage.

demand-first-review