Conception simple

XP a un mantra : Faites la chose la plus simple qui pourrait possiblement fonctionner.

Il ne s'agit pas d'être paresseux ou d'écrire du code bâclé. Le code simple est souvent plus difficile à écrire que le code complexe. Cela nécessite :

• Comprendre le problème en profondeur
• Résister à l'envie de généraliser
• Dire « non » à la spéculation
• Faire confiance au fait que vous pourrez changer les choses plus tard

Le code simple est :

• Facile à comprendre
• Facile à modifier
• Facile à tester
• Juste suffisant pour les besoins actuels

Le code complexe est :

• Difficile à comprendre
• Risqué à modifier
• Difficile à tester
• Construit pour des besoins futurs imaginés qui pourraient ne jamais se concrétiser

YAGNI est le principe selon lequel vous ne devriez construire que ce dont vous avez besoin maintenant.

N'ajoutez pas :

• Des fonctionnalités parce qu'elles « pourraient être utiles »
• Des options de configuration parce que les utilisateurs « pourraient les vouloir »
• Des points d'extension parce que le code « pourrait en avoir besoin »
• Des abstractions pour des exigences futures hypothétiques

Pourquoi ? Parce que :

• Vous avez généralement tort sur ce dont vous aurez besoin
• Le code inutilisé a quand même un coût de maintenance
• Chaque abstraction a un prix en complexité
• Construire pour l'avenir retarde la livraison pour aujourd'hui

Le pari XP : Si vous avez besoin de quelque chose plus tard, vous pouvez l'ajouter plus tard. Avec TDD, le refactoring et l'IC, le changement est peu coûteux. Alors ne payez pas pour l'avenir avant d'y être obligé.

C'est une idée radicale. Le génie logiciel traditionnel dit d'anticiper le changement et de concevoir pour la flexibilité. XP dit d'attendre d'en avoir réellement besoin.

Kent Beck a défini la conception simple comme du code qui :

1. Passe tous les tests Le code fonctionne. C'est non négociable. Une belle conception qui ne fonctionne pas ne vaut rien.

2. Révèle l'intention Le code est facile à comprendre. Bons noms, structure claire, organisation lisible. Quelqu'un de nouveau peut le prendre et comprendre ce qu'il fait.

3. N'a pas de duplication (DRY) Chaque élément de connaissance est exprimé une fois et une seule fois. La duplication crée un fardeau de maintenance et un risque de bogues.

4. A le moins d'éléments Pas de classes, méthodes, variables ou abstractions supplémentaires. Tout ce qui existe a une raison d'exister.

Les règles sont dans l'ordre de priorité. Passer les tests l'emporte sur tout. Mais une fois les tests passés, favorisez la clarté plutôt que le DRY. Et n'ajoutez que des éléments qui servent les trois premières règles.

La conception simple ne signifie pas l'absence de conception. Elle signifie conception incrémentale—faire évoluer la conception au fur et à mesure que vous apprenez.

Le processus :

1. Commencez avec l'implémentation la plus simple qui fonctionne
2. Au fur et à mesure que vous ajoutez des fonctionnalités, remarquez les frictions (ça devient maladroit)
3. Refactorisez pour résoudre les frictions
4. La conception émerge de besoins réels, pas de spéculation

C'est pourquoi XP met tellement l'accent sur le refactoring. Si vous ne pouvez pas changer le code en toute sécurité, vous ne pouvez pas faire de conception incrémentale. Vous êtes coincé avec ce que vous avez construit en premier.

La conception initiale exhaustive (BUFD) échoue parce que :

• Vous n'en savez pas assez au départ
• Les exigences changent
• Les conceptions ne survivent pas au contact avec la réalité
• Vous payez pour une complexité que vous n'utilisez jamais

La conception incrémentale réussit parce que :

• Vous concevez en fonction de besoins réels
• La conception évolue avec la compréhension
• Vous ne payez jamais pour ce que vous n'utilisez pas
• Le refactoring maintient la conception propre

La conception simple ne signifie pas éviter toute complexité. Parfois, la complexité est nécessaire.

Ajoutez de la complexité quand :

• Les tests l'exigent (faites-le passer)
• La clarté l'exige (révélez l'intention)
• L'élimination de la duplication l'exige (DRY)
• Les exigences actuelles et réelles en ont besoin

N'ajoutez pas de complexité pour :

• Des scénarios « Et si ? »
• D'éventuelles fonctionnalités futures
• Des frameworks dont vous pensez avoir besoin
• Rendre le code « plus flexible »

La différence est entre la complexité essentielle (inhérente au problème) et la complexité accidentelle (introduite par votre solution). XP minimise la complexité accidentelle en refusant de construire pour des exigences imaginaires.

Lorsque vous avez besoin d'une abstraction, laissez-la émerger de l'élimination de la duplication. La « règle de trois » est utile : n'abstraisez pas avant d'avoir vu le même motif trois fois. À ce moment-là, vous comprenez les variations réelles, pas celles imaginées.