ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: À utiliser lors de l'écriture ou de la modification de code, avant de considérer la tâche terminée, chaque fois que le changement ajoute un nom exporté ou importable, crée un module, une classe, un composant, un helper, un hook, un service ou un wrapper, ou centralise du code répété. Liste de contrôle à l'auteur pour construire des modules profonds : nommer la décision que la frontière cache, passer les tests de profondeur et d'invariant, corriger les problèmes au lieu de les déplacer, ne jamais diviser uniquement en fonction de la taille, et terminer par une courte note de conception. Compagnon compact de ousterhout-quality-program, qui reste la lentille complète de revue.
---

# Build it deep (Ousterhout, author-time)

Vous écrivez du code, pas vous ne le révisez. Exécutez ceci sur votre propre modification avant
de considérer la tâche comme terminée.

## 1. Porte

Le changement ajoute-t-il un nom exporté/importable, crée-t-il un module, une classe,
composant, helper, hook, service ou wrapper, ou centralise-t-il du code répété ?
Si non, passez cette compétence. Les renommages, codemods, modifications de config/données et corrections d'une ligne sont exemptés.

## 2. Avant d'écrire la frontière

- Trouvez comment ce dépôt résout déjà un problème de cette forme et suivez-le
  sauf si vous pouvez expliquer pourquoi pas. Lisez la documentation et
  les types actuels de la dépendance : une API rappelée de mémoire est une affirmation, pas une source.
- Écrivez d'abord le commentaire d'interface : ce qu'elle promet, ce qu'elle cache. Si
  vous ne pouvez pas nommer la décision cachée (un format, une politique, une règle, un
  choix de schéma), la frontière ne devrait pas exister. Intégrez-la.
- Nommez-la dans le langage du domaine. Si le seul nom honnête est `utils`,
  `helpers` ou `manager`, la séparation est mal placée.

## 3. Deux tests

- **Profondeur.** L'interface doit cacher substantiellement plus qu'elle n'expose. Un
  wrapper qui transmet ses arguments est un coût sans bénéfice ; supprimez-le.
- **Invariant.** N'extrayez du code partagé que lorsqu'il protège une règle partagée.
  La preuve est la co-modification : les copies ont été corrigées ou modifiées ensemble dans
  l'historique. Les ressemblances qui changent indépendamment restent dupliquées.

## 4. Une correction doit supprimer le problème, pas le déplacer

- Six cast déplacés dans un helper générique de cast restent six cast. Écrivez
  le mapper typé que les cast masquaient.
- N'ajoutez pas un paramètre ou un flag qui repousse une décision sur les appelants à moins que
  les appelants ne sachent vraiment quelque chose que vous ne savez pas. Absorbez le cas difficile à l'intérieur.
- Préférez une sémantique où le cas d'erreur ne peut pas survenir plutôt que de faire gérer chaque
  appelant.
- Déplacer une complexité essentielle du domaine dans un autre fichier n'est pas une simplification.

## 5. Sous la pression de « nettoyer ça » ou « ce fichier est trop gros »

Ne divisez jamais sur la seule taille. Un module de 400 lignes cachant une décision vaut mieux
que quatre modules de 100 lignes fuyant les mêmes jonctions. Demandez quelle décision chaque division
cache ; si aucune, ne divisez pas.

## 6. Sécurité

Code existant : fixez le comportement actuel avec un test avant de l'approfondir. Code nouveau : écrivez le test qui définit le comportement attendu.

## 7. Rapport

Si la porte s'est déclenchée, terminez votre message final par une note de conception de 2-4 lignes : chaque
frontière que vous avez ajoutée et la décision qu'elle cache ; duplication laissée volontairement et pourquoi ; tout ce qui est superficiel que vous avez accepté et pourquoi.

Pour un appel contesté ou une revue complète, chargez `ousterhout-quality-program`.

Tags