[3 Mots Du Moment] Indirection, Délégation, Amender

Dans cette rubrique je présente 3 mots que j’aime ou déteste, que je prononce trop ou que je viens d’apprendre.

Dans cette rubrique je présente 3 mots que j’aime ou déteste, que je prononce trop ou que je viens d’apprendre. Mes 3 mots du moments concernent la conception et l’architecture logicielle. Je les utilise en programmation à deux, en séance d’architecture, avant d’entamer une fonction ou durant la mêlée quotidienne.

Indirection

Souvent utilisé avec “Niveau”.

Péjoratif : “On a trop de niveaux d’indirection. Il y a trop de couches entre l’API et son implémentation. Il faut simplifier.”

Positif : “Grâce à cette façade on expose pas directement l’implémentation, on fait une indirection qui nous laisse de la souplesse.”

Délégation

Dans la même veine. Un bon moyen d’ajouter une indirection.

Surtout en Objective-C, l’héritage est vraiment une solution inconfortable. Alors on use et abuse des délégués. C’est un super moyen de passer les responsabilité aux bons objets. C’est aussi une alternative aux notifications globales. Parfois seul un délégué doit être prévenu, pas besoin de diffuser un message à tous les potentiels classes intéressées.

Amender

Toujours en Objective-C, un bon moyen de ranger le code, faciliter la maintenance et pratiquer le TDD c’est d’utiliser des Category. On amende la classe pour ajouter les méthodes sur un sujet précis (aspect présentation, persistance, etc…)

Autre contexte : dans notre pratique de SCRUM, lorsqu’un bug est trouvé sur une tâche on amende le post-it pour signaler un problème (en gros on ajouter un autre post-it qui explique le bug)

5 reasons to read “Refactoring To Patterns” by J.Kerivsky

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

You have to read “Refactoring To Patterns” from J.Kerievsky because :

1. Design patterns are good but…

Project begins. You read specifications (if there are some, or if they are more than one page long), you go to your DoodleTop and you start the conception.

And then comes this moment, you know when you say : “Cool ! I’ll put a Singleton here, 3 abstract factories there and a flyweight over here”.

Of course, specifications are missing or you are just suspicious (and you are right). So you harden and generalize your conception. And of course, it shows all you colleagues that you know your pattern 101.

End of the project (=deadline +150%) :

Colleague A

Hey man, what’s all this stuff in your conception all about ?

You know : just in case !

Fail.

Debugging is painful, nobody can understand your code, event you and most of all : to add one tiny option your colleague must re-invent the wheel, without using your conception at all.

That’s what the author calls over-engineering.

The opposite exists also and is called (you guessed it) : under-engineering. When you want to add one feature you have to break everything.

This is why :

2. …refactoring to patterns is better !

This is the whole point of “Refactoring To Patterns”. First because you must not wait for the end of the project to refactor and clean the code. Then : because it’s natural to refactor ! A product evolves and specs change over the project time.

Patterns emerge more precisely when project has already started and you spend more time coding.

3. You don’t have to read it from page 1 to 367

Pretty cool. Because even if this book is more a page turner than a lot of the same style, it’s better to study patterns when you really need them, not in your bed during your vacations.

You can read :

in the order of the pages,
in the order of the examples (the author gives a table of all chapters grouped by same examples),
by patterns,
by conception problems.

And it stays clear. Really good.

4. Chapters are really well structured (sometimes too much)

In each chapter you find :

A summary of the problem as a before/after UML diagram.
A long description (Motivation) about pros and cons (with much honesty) of this refactoring and a summary at the end.
A step-by-step (Mechanics) section describing very generically how to apply this refactoring. For example : rename this method, then remove this variable, compile and test, then paste this variable elsewhere etc… You don’t have to read this section at the first time (that’s the authors suggestion). I think that if you’d paste all those steps in an application you’d have an Eclipse refactoring plugin.
An example : the best part because…

5. Examples are not “foo” and “bar”

Examples are real world applications. And the author uses them a lot. So at the end you know perfectly 4 or 5 examples and that’s all. They are clear but not to simple. This is rare enough to note it.

6. To conclude

What’s pleasant is that the authors knows that refactoring to pattern is sometimes overkilling.

This is honest and reassuring. Hence you read without gilt of not having refactor before, because sometimes you don’t need to. And it’s never too late to begin. That’s the principle of on-the-go refactoring.

Question for the readers out there who work with Agile : does refactoring have more space in the Agile methodology ?

And you ? Do you practice refactoring a lot ? Or are you afraid to break everything ? Do you simply have time to do it ?

http://jbrieu.info/leblog/2010/gribouilletop-viens-gribouiller-sur-mon-bureau-doodletop-i-doodle-on-my-desk-and-i-like-it/?lang=en

5 raisons pour lire « Refactoring To Patterns » de J. Kerievsky

[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 ?

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 ?