Razor
La conception correcte est la moins coûteuse qui répond totalement au besoin réel de l'utilisateur — rien de plus pour des besoins qui n'existent pas encore. Deux coupes : trouver le besoin, puis adapter la solution.
1. Trouver le vrai besoin. Ce que les gens demandent est une solution qu'ils ont déjà imaginée, pas le besoin sous-jacent — et ce qu'ils disent n'est souvent pas ce qu'ils pensent. La demande énoncée, la solution imaginée et le besoin réel sont trois choses différentes. Reconstruisez le besoin à partir des principes de base : à qui cela s'adresse-t-il, et que cherchent-ils vraiment à faire, maintenant. Vous ne pouvez pas couper contre une cible que vous n'avez pas trouvée — si ce n'est pas clair, demandez.
2. Adapter la solution (Occam). La conception correcte est le nombre minimum de pièces mobiles qui répondent à ce besoin ; chaque couche, option, abstraction ou garde supplémentaire est un coût — à construire, lire, tester, casser et modifier — à moins qu'un besoin présent ne le justifie. Pour trouver le minimum, arrêtez-vous au premier échelon qui tient :
- Est-ce que cela doit exister ? → non : abandonnez (YAGNI).
- Est-ce que quelque chose le résout déjà — ce code, la bibliothèque standard, une fonctionnalité de la plateforme, une dépendance installée ? → utilisez-le, ne le construisez pas.
- Peut-on faire une chose évidente au lieu d'un système ? → faites cela.
Paresseux sur la solution, jamais sur la compréhension du problème.
Processus
- Reconstruisez le vrai besoin (coupe 1) ; énoncez-le en une ligne.
- Dérivez la conception minimale — partez de la chose la plus bête qui fonctionne, n'ajoutez que ce que le besoin impose (coupe 2).
- Comparez la proposition avec cette conception. Tout ce qui est en trop est un candidat à la coupe ; nommez le signal d'alarme (YAGNI, abstraction prématurée, sur-défense, réinvention, option spéculative).
- Ne coupez pas trop. Relisez le besoin et remettez tout ce qu'il nécessite réellement. Étroit ≠ fragile — ne coupez jamais la validation, la gestion des erreurs, la sécurité ou l'accessibilité réelles.
Sortie
Utilisez ce modèle et restez concis — un scalpel, pas un essai :
## Vrai besoin
<une ligne — ce dont l'utilisateur a vraiment besoin, pas ce qu'il a demandé>
## Conception minimale
<l'approche la plus étroite qui y répond>
## Coupe comme sur-conception
- <chose> — <signal d'alarme + pourquoi aucun besoin présent ne la justifie>
## Conserver (ne pas sur-couper)
<tout ce qui semble coupable mais qui est réellement nécessaire, pour ne pas être supprimé plus tard.
Omettre cette section si rien ne se qualifie.>
Si la conception est déjà minimale, dites-le et arrêtez-vous.