OU SONT LES GOF?

J'ai noté une mutation dans mon entourage. Peut-être l'avez-vous également remarqué autour de vous.

Il y a quelques années, nous avions tous un exemplaire du GoF sur notre bureau. L'ouvrage Design Patterns de Gamma, Heml, Johnson et Vlissides (le Gang of Four) était Le Livre. Pour nous, ce catalogue était La Référence des programmeurs compétents. Il trônait fièrement sur nos bureaux et nos architectures étaient enrichies de ses enseignements.

Puis, il nous a fallu plusieurs années pour graduellement et efficacement mettre en pratique l'Extreme-Programming. Curieux constat, aujourd'hui le GoF ne trône plus sur aucun de nos bureaux. Le mien est à la maison.

Comment expliquer cette lente mutation? Voici quelques causes possibles:

1. Nous ne concevons plus, nous codons comme des coyotes (alternative sauvage du cowboy-coding);


2. Nous maitrisons les Design Pattern et les mettons en musique de manière intuitive et inconsciente (rien que cela);


3. Nous concevons autrement, piloté par les tests;


4. Nous connaissons suffisamment les design-pattern et nous les faisons émerger avec parcimonie à mesure de la conception pilotée par les tests (fromage et dessert).

Alors, est-ce un abandon, une digestion, une révolution ou une mutation?

Sur plusieurs projets d'affilée, j'ai remarqué que je me fais moins de nœuds au cerveau concernant l'architecture. Avant, nous réfléchissions pas mal avant de nous mettre sérieusement au code. Nous dessinions de nombreux modèles au tableau et nous potassions le GoF à la recherche d'élégantes solutions.

Désormais, nous sommes plus directs. Nous cherchons la solution la plus simple à tester tout en respectant le principe de séparation commande/requête. Les associations, abstractions, héritages et implémentations viennent naturellement sur des critères de testabilité. Une fois que les tests passent, nous remanions notre travail pour réduire le volume de code, notamment en chassant les duplications. Au passage, nous nous assurons que l'organisation des classes respecte les principes de l'Oncle Bob. Et le plus incroyable est qu'au fur et à mesure des projets, il est de plus en plus aisé d'ajouter des fonctionnalités par incrément. Je trouve même que nos architectures sont élégantes. Elles ont l'élégance de la simplicité. Au passage, nous constatons que nos critères d'une bonne architecture sont par ordre de priorité: testabilité, simplicité, pas de dupplication, clarté.

Je ne pense pas pour autant que nous négligeons les patterns du GoF. Après en avoir abusé, nous les appliquons avec plus de parcimonie. En effet, dans nos architectures nous retrouvons toujours une séparation claire des responsabilités de fabrication des instances, d'utilisation des instances, de séquencement des instances et de gestion des états. Par contre, les Singleton sont toujours une vraie plaie pour les tests.

Ainsi, nous n'avons pas brulé nos GoF. Nous avons pris le temps d'en assimiler les enseignements et de les appliquer sans en abuser. Mais, je reconnais que pour nous, le GoF n'est plus La Référence. Nous n'en conseillons plus la lecture aux nouveaux arrivants. Ainsi, nous nous reposons peut-être trop sur l'expérience de ceux qui l'ont lu et l'ont trop pratiqué pour enfin apprendre à bien le pratiquer.

Et vous, il est où votre GoF?