mardi 20 janvier 2009

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?

8 commentaires:

  1. Toujours sur mon bureau...
    Ben oui nous on n'a pas encore "muté" :-)

    RépondreSupprimer
  2. Hello Aline,
    (désolé, je dois toujours répondre à un de tes mails)
    Le truc est que je ne suis pas sûr qu'il faille muter.
    Le GoF est-il toujours en vogue? Est-ce toujours Le Livre?
    Est-il nécessaire de pratiquer le GoF ou est-ce que le TDD peut-être suffisant?
    En tout cas, je ne pense plus qu'il faille "maîtriser" le GoF pour faire de bonnes architectures. Je pense que le TDD est une aide plus pragmatique. Par contre, je pense qu'il aide pour converger plus vite vers une bonne architecture.

    RépondreSupprimer
  3. Chez nous il n'a jamais été en vogue avant une petite "autoformation" il y a à peine quelques semaines, avec une introduction aux design patterns pour ceux qui viennent de se mettre à la programmation orientée objet. C'est mon livre perso que j'ai apporté pour essayer d'en parler un peu et d'expliquer qu'on peut parfois se servir d'un design pattern quand on a des cas particuliers de conception.

    Mais bon comme je le redis, on n'est pas passé à du TDD, d'ailleurs c'est pas demain la veille. On est encore en train d'apprendre à faire du code maintenable, qui soit possible de filer à quelqu'un d'autre pour qu'il continue le boulot derrière, refactoré, etc... Alors là je confirme, le GOF apprend vraiment beaucoup (et rapidement, comme tu le dis) pour les débutants, et permet d'aller rapidement vers quelque chose de "lisible". Pour le reste... RDV dans quelques mois ;-)

    Pour le mail, ne réponds que si t'as le temps et rien d'autre à faire ! c'est pas grave sinon !

    RépondreSupprimer
  4. Bonjour,

    Oui, je crois que pour beaucoup, les GoF sont à la fois devenus implicites à force de les utiliser, et moins indispensables grâce à la volonté de simplicité.
    Sinon, pour ceux que ça intéresse, une interview récente de Erich Gamma (le 1 des 4 GoF) sur infoQ : http://www.infoq.com/interviews/gamma-jazz-eclipse-junit-design-patterns

    RépondreSupprimer
  5. Peut-être qu'en XP un bouquin sur le refactoring devient beaucoup plus utile qu'un bouquin sur les patterns.

    RépondreSupprimer
  6. Denis,
    Je suis assez d'accord qu'en XP, nous avons plus tendance à remanier le code en faisant éventuellement émerger des Design Patterns qu'à les anticiper.
    En effet, le livre Refactoring de Martin Fowler doit sûrement remplacer le GoF sur quelques bureaux.

    Pascal,
    je suis d'accord que le GoF est devenu implicite pour ceux qui l'ont beaucoup utilisé (voire abusivement, comme moi à un certain moment ;o).
    Je suis aussi d'accord qu'a force d'injecter des patterns dans l'architecture, on arrive à un stade où c'est impressionnant, mais plus très clair ...

    RépondreSupprimer
  7. A ce sujet, vous connaissez peut être le livre Refactoring To Patterns de Joshua Kerievsky?
    Il s'agit de faire émerger des design-patterns judicieusement par remaniement.

    RépondreSupprimer
  8. Bien observé ! J'ai acheté le mien en 1997, j'étais fier d'être un pionnier à l'époque - mais il prend la poussière ces derniers temps.

    Sinon, j'essaie maitenant de réaliser ta proposition 4, fromage et dessert.

    J'ai constaté récemment les dégats causés par l'application à outrance de design patterns, sous forme de "sur-conception", qui avait conduit à du code incompréhensible tellement il y avait d'indirections. Et aucun bénéfice métier. C'est un exemple des "provisions" que l'agilité nous enseigne à ne plus faire.

    Finalement j'en suis même à préférer du code simple avec quelques "if" à des implémentations obscures de patterns !

    L'idéal me paraît de connaître les patterns pour pouvoir (au besoin) guider une conception dirigée par des tests - au sens du TDD bien sûr.

    Bruno

    RépondreSupprimer