Tag: livre

[avhamazon locale=”US” asin=”0321213351″ linktype=”pic-text” picsize=”medium”]

Il faut avoir lu “Refactoring To Patterns” de J.Kerievsky parceque  :

1. Les design patterns c’est bien mais…

Le projet commence. On lit les spécifications (quand il y a en a, ou qu’elles font plus d’une page), on se penche sur son GribouilleTop et on commence la conception.

Et puis arrive le moment fatidique où on se dit : “Trop bien! Je vais mettre un singleton ici, 3 fabriques abstraites là et un flyweight à cet endroit”.

Normal, les spécifications manquent ou bien on est juste méfiant (et on a raison). Donc on se blinde. En plus ça montre aux autres qu’on connait les patterns sur le bout du clavier. La classe.

Fin du projet (=date prévue +150%) :

Collègue

Dis-moi, Machin, ça sert à quoi tout ce système ?

Jb

Au cas où !

Perdu.

Le déboguage est compliqué, personne ne comprend rien et surtout pour ajouter une option le collègue réinvente la roue, sans passer par votre super implémentation.

C’est ce que l’auteur appelle l’over-engineering (la sur-conception).

A noter que la même chose est possible dans l’autre sens : l’under-engineering (la sous-conception). Dès qu’on veut rajouter une option il faut tout casser.

Voilà pourquoi :

2. …le refactoring vers les patterns c’est mieux !

C’est tout l’argument de ce livre. D’abord, ne pas attendre pour modifier sa conception que la fin du projet arrive. Ensuite parce que c’est normal ! Un produit évolue, et on ne peut pas penser à tout.

Les patterns apparaissent beaucoup plus clairement quand on a commencé à se plonger régulièrement dans le code, et moins au début.

3. Vous n’êtes pas obligé de lire le livre dans l’ordre.

Et ça c’est plutôt cool. Parce que même si, entre nous, on s’endort moins qu’en lisant d’autres livre de ce style, c’est quand même sympa de pouvoir étudier tous ces patterns au moment ou ils sont le plus parlant pour nous.

Vous pouvez lire :

• dans l’ordre des pages,
• par ordre des exemples (l’auteur donne une table des chapitres qui utilisent le même exemple),
• par pattern,
• par problèmes de conception.

Et le tout reste très clair. Vraiment bien.

4. Les chapitres sont très bien structurés (parfois trop)

Dans chaque chapitre on trouve :

• Un résumé sous forme de schéma avant/après le refactoring et dans quels cas appliquer ce refactoring.
• Une longue description (Motivation) sur les pour et les contres (avec beaucoup d’honnêteté) de ce refactoring et un résumé à la fin.
• Une section “Algorithme”(Mechanics) qui décrit vraiment très génériquement comment appliquer pas à pas le refactoring. Par exemple : renommez la fonction, puis retirez cette variable, compilez et testez, puis collez cette variable ailleurs etc… Cette section peut être évitée à la première lecture (ce que j’ai fait puisque l’auteur nous y invite) et on y perd rien. Je pense que si on collait tous ces algorithmes dans une application on obtiendrait un plugin Eclipse de refactoring, tout simplement.
• Un exemple : entre nous la meilleure section parceque…

5. Pour une fois les exemples ne sont pas “foo” et “bar”.

Les exemples sont des applications et des cas réels que l’auteur expose largement. On les retrouve tout au long du livre et ils sont très clairs. C’est assez rare pour être souligné.

6. En conclusion.

Ce qui est plaisant c’est que l’auteur reconnait qu’il y a des cas ou reconçevoir en pattern n’est pas utile, ou trop lourd. C’est rassurant et honnête. Du coup on lit sans culpabiliser de ne pas y avoir pensé plus tôt. D’ailleurs, il est toujours temps de faire du refactoring. C’est justement le principe.

Question pour ceux qui travaillent en Agile : est-ce qu’on est plus enclin à pratiquer le refactoring que dans une gestion de projet classique ?

Et vous ? Pratiquez-vous le refactoring intensif ? Pas trop peur de tout casser ? Vous en avez le temps ?