Que fait Discipline du Code Minimal ?
Utilisez cette compétence pour appliquer une discipline de code minimal (échelle YAGNI) lors de la planification et de l'écriture de modifications de code. Elle permet de garder les diffs petits et évidemment corrects sans sacrifier les vérifications qui protègent les utilisateurs.
Cette compétence complète ai-slop-cleaner : ce dernier nettoie le code superflu après son arrivée ; celle-ci l'empêche d'être écrit.
Quand l'utiliser
Utilisez cette compétence lorsque :
- l'utilisateur demande une implémentation minimale, économe, YAGNI ou avec le plus petit diff possible
- un plan ou une modification en cours dépasse la demande initiale
- vous écrivez du nouveau code où des dérives de périmètre, des helpers réinventés ou de la généralité spéculative sont probables
- vous examinez un diff proposé pour sa taille avant implémentation
Quand ne pas l'utiliser
N'utilisez pas cette compétence lorsque :
- l'utilisateur demande explicitement une construction large, riche en fonctionnalités ou conçue pour le futur (son périmètre explicite prévaut)
- la tâche est un échafaudage exploratoire que l'utilisateur a marqué comme jetable
- la pression de minimisation toucherait un comportement protégé (voir Non-Négociables)
La Discipline
Existence d'abord. Demandez-vous si la modification a besoin d'exister ; sautez le travail qui ne sert qu'un besoin futur spéculatif.
Réutilisation avant écriture. Recherchez dans la base de code un helper, un type ou un motif existant avant d'écrire quoi que ce soit de nouveau. Ne copiez jamais un helper qui vit déjà à quelques fichiers de distance — réutilisez-le ou extrayez-le vers un emplacement partagé.
Échelle de dépendances. Utilisez d'abord la bibliothèque standard, puis les capacités natives de la plateforme, puis une dépendance déjà installée. Le code écrit à la main est le dernier recours. N'introduisez pas une nouvelle dépendance quand quelques lignes de code suffisent, sauf si l'utilisateur l'a explicitement demandée ou approuvée.
Comprendre avant de minimiser. Lisez le code affecté et suivez son chemin d'exécution d'abord. Livrez le diff correct le plus court une fois le problème compris — le code que vous n'écrivez jamais ne plante jamais.
Ennuyeux plutôt qu'astucieux. Préférez un code ennuyeux et évidemment correct à un code astucieux.
Marquez la limite. Enregistrez les simplifications délibérées avec un court commentaire nommant la limite acceptée et ce qui justifierait de la remplacer.
Cause racine, pas symptômes. Corrigez les bogues à la cause racine partagée par tous les appelants, pas avec un correctif séparé pour chaque symptôme signalé.
Non-Négociables
Ne minimisez jamais :
- la validation partout où une frontière de confiance est traversée
- la gestion des erreurs qui protège contre la perte de données
- les contrôles de sécurité
- les fondamentaux d'accessibilité
- le périmètre que l'utilisateur a explicitement demandé
Vérification
Avant de signaler la fin, confirmez :
- chaque ligne ajoutée a sa raison d'être (pas de généralité spéculative, pas de helpers en double)
- le diff est le plus court qui résout correctement le problème énoncé
- les non-négociables sont intacts
- les tests passent toujours et le comportement est inchangé sauf comme demandé