Here is my review for Refactoring: Improving the Design of Existing Code by Martin Fowler
My Ultra Brief Summary: Liked it.
If you have to maintain an application archtected by a demonically possessed programmer with evil intent (you may know this entity very intimately), then this publication of power could be just what you are after. This treatise against technical tyranny contains magical incantations and rituals designed to excise these hell spawned demons from your software.
How can this be, you query? Is not the brutal beast of bugality invulnerable? In attempting to squash this bothersome beetle do you not incur the wrath of the slimy serpent of spaghetti software? or the trinity of undead unnamables: unreadability, unmaintainablity and unemployment?
Nay I say, once you are adept at anti-arthropodic alchemy, you too will be fearless of the ferocious...
Okay I think that's ample alliteration...
Firstly what is refactoring? Well, it doesn't really have as much to do with battling evil as I may have implied above. A basic (and clear) definition is "any change to a computer program which improves its readability or simplifies its structure without changing its results". Or simpler "improving code without breaking it". Now you know what refactoring is, is the book any good?
Yes is my short answer. The longer answer:
I certainly enjoyed reading this book which sounds very geeky due to it's technical nature. It's content has little humor in it, thus my enjoyment must stem from the fact that the information contained within it's hard bound jacket was useful - and it certainly is. I've started looking at adding features and bug fixing in a new way, although I don't think I've altered my behaviour significantly as yet - but I could be wrong as programming is quite an unconscious behaviour. I have also gleaned a much better appreciation of what is good code and what is what should be tidied up - a property that is described in the book as smell (does this make refactoring a deodoriser?).
The refactorings are grouped by topic with each refactoring starting on a fresh page, making this quite good as a reference book, but even so I found it okay reading from cover to cover. Inside you will find numerous methods of changing code step by step so as not to introduce (additional) defects.
The code examples are in Java, so you JBuilder guys and gals have an advantage (over us turbo and studio people), although you don't need to have an intimate knowledge of Java to work out the examples - I could follow and I've never written any Java in my life. It also helps if you know a little UML, if you don't you can always read one of Martin Fowlers other books. Knowing UML is useful anyway especially if you want to get into ECO or the Together support within Developer Studio.
Most IDEs these days have built in support for refactoring, Developer Studio included and you'll be able to take better advantage of it if you've read this book.
If you don't like my review you can read others on amazon.com or even buy this book but only do so if you are going to actually read it. It wont do you any good just sitting on your book shelf, as it is not the kind of thing that impresses the chicks. To do that buy a Ferrari instead, although they may think is compensation for something else, I only say this because I don't have one - a Ferrari that is.