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