Concevoir une Interface

D'après « Design It Twice » de « A Philosophy of Software Design » : votre première idée n'est probablement pas la meilleure. Générez plusieurs designs radicalement différents, puis comparez.

Workflow

1. Recueillir les Exigences

Avant de concevoir, comprenez :

[ ] Quel problème ce module résout-il ?
[ ] Qui sont les appelants ? (autres modules, utilisateurs externes, tests)
[ ] Quelles sont les opérations clés ?
[ ] Y a-t-il des contraintes ? (performance, compatibilité, patterns existants)
[ ] Qu'est-ce qui doit rester caché vs exposé ?

Posez-vous : « Que doit faire ce module ? Qui l'utilisera ? »

2. Générer des Designs (Sous-Agents Parallèles)

Lancez 3+ sous-agents simultanément via l'outil Task. Chacun doit produire une approche radicalement différente.

Modèle de prompt pour chaque sous-agent :

Concevez une interface pour : [description du module]

Exigences : [exigences recueillies]

Contraintes pour ce design : [assignez une contrainte différente à chaque agent]
- Agent 1 : « Minimisez le nombre de méthodes - viser 1-3 méthodes max »
- Agent 2 : « Maximisez la flexibilité - support de nombreux cas d'usage »
- Agent 3 : « Optimisez pour le cas d'usage le plus courant »
- Agent 4 : « Inspirez-vous de [paradigme/bibliothèque spécifique] »

Format de sortie :
1. Signature de l'interface (types/méthodes)
2. Exemple d'utilisation (comment l'appelant l'utilise)
3. Ce que ce design cache en interne
4. Trade-offs de cette approche

3. Présenter les Designs

Montrez chaque design avec :

Signature de l'interface - types, méthodes, paramètres
Exemples d'utilisation - comment les appelants l'utilisent concrètement
Ce qu'il cache - complexité restée interne

Présentez les designs séquentiellement pour que l'utilisateur assimile chaque approche avant la comparaison.

4. Comparer les Designs

Après avoir montré tous les designs, comparez-les sur :

Simplicité de l'interface : moins de méthodes, paramètres simples
Usage général vs spécialisé : flexibilité vs focus
Efficacité d'implémentation : la forme permet-elle une implémentation efficace ?
Profondeur : petite interface cachant une complexité importante (bon) vs large interface avec implémentation mince (mauvais)
Facilité d'utilisation correcte vs facilité de mésusage

Discutez des trade-offs en prose, pas en tableaux. Mettez en évidence où les designs divergent le plus.

5. Synthétiser

Souvent, le meilleur design combine des idées de plusieurs options. Demandez-vous :

« Quel design s'adapte le mieux à votre cas d'usage principal ? »
« Y a-t-il des éléments d'autres designs qui valent la peine d'être incorporés ? »

Critères d'Évaluation

D'après « A Philosophy of Software Design » :

Simplicité de l'interface : Moins de méthodes, paramètres simples = plus facile à apprendre et utiliser correctement.

Usage général : Peut gérer les cas d'usage futurs sans changements. Mais attention à la sur-généralisation.

Efficacité d'implémentation : La forme de l'interface permet-elle une implémentation efficace ? Ou force-t-elle des internals maladroits ?

Profondeur : Petite interface cachant une complexité importante = module profond (bon). Large interface avec implémentation mince = module peu profond (à éviter).

Anti-Patterns

Ne laissez pas les sous-agents produire des designs similaires - imposez une différence radicale
N'omettez pas la comparaison - la valeur est dans le contraste
N'implémentez pas - c'est purement une question de forme d'interface
N'évaluez pas en fonction de l'effort d'implémentation

design-an-interface