_Speaking of refactoring, for a while now I have been reading Martin Fowler’s Refactoring (great book btw). I was visiting some links listed on Martin’s site, when I came accross Josh Kerievsky’s e-book: Refactoring to Patterns. I have only had a couple of minutes to skim through it, but it looks very promising (especially if you don’t have Martin’s book) _
Martin’s Refactoring is one book that is ALWAYS out on my desk. It gets opened at least once a week. People love to talk about how patterns have saved software development, but for me it was refactoring.
If you already know about Martin Fowler’s Refactoring book (and its accompanying website), then you also should download and review the e-book Scott mentions in his post: Refactoring to Patterns. It isn’t complete, so don’t expect it to be the kind of bible that Refactoring is. But it is an excellent bridge between the GoF Patterns book and Refactoring.
This is my favorite quote from Refactoring to Patterns:
When you make your code more flexible or sophisticated than it needs to be, you over-engineer it. Some do this because they believe they know their system?s future requirements. They reason that it?s best to make a design more flexible or sophisticated today, so it can accommodate the needs of tomorrow. That sounds reasonable, if you happen to be a psychic.
But if your predictions are wrong, you waste precious time and money. It?s not uncommon to spend days or weeks fine-tuning an overly flexible or unnecessarily sophisticated software design?–leaving you with less time to add new behavior or remove defects from a system.
This is a classic violation of the XP YAGNI principle… You Ain’t Gonna Need It. I wonder if anyone has considered something like CMM for patterns adoption. It might go something like this:
- You discover patterns. You don’t really see what all the hype is about.
- You read the GoF book and actually use a pattern in a program.
- You learn and understand what patterns are really all about. You know all of the GoF patterns and try to use them whenever possible. You violate YAGNI every day you code.
- After building one last excessively complicated program, you realize that patterns are another useful tool, but they are not the end-all-be-all of software development.