7 of 7 people found the following review helpful
on 12 October 2001
Like the GoF book, this book makes new ground by describing each refactoring in baby-step format and *naming* each of the refactorings. It has also led to more refactoring tools (which I hope will become a mandatory IDE requirement). So, instead of having to refactor your code manually, you can simply goto the menu and select "Extract Method", "Replace Temp with Query" etc. I highly recommend people check out the new IntelliJ IDEA (called Pandora). As Kent Beck notes, a refactoring tool completely changes the way you think about coding.
10 thumbs up for this book and the effect it will have on the industry.
5 of 5 people found the following review helpful
on 8 December 2009
Great ideas in software are often met with the "if you've been around as long as me, then you know this stuff already" line. WHO CARES?!! Often in fields involving know-how, the most "obvious" things (techniques, principles) *need* to be revisited, re-stated (out loud, as it were), just to plant our feet back on the ground, to reacquaint us with the foundations. I approached this book with scepticism but after reading a chapter and skimming through the rest, I was already re-enthused on a software project I had become disillusioned with. The results are an order of magnitude better: lean, clear, crisp, efficient. It'll make you proud to show your code to others!
36 of 39 people found the following review helpful
on 15 August 2002
I'm probably not alone in finding that, upon opening up source code (even my own), I have an uncontrollable urge to remove duplication, simplify, reduce and generally "improve" things before I can start to see how changes can be made. Then I read this book and discovered that I was refactoring.
Even better, I started to understand that there were a set of well-designed methods to apply, some of which I'd informally discovered for myself (so I wasn't alone after all) and many more that I hadn't thought of. It doesn't hurt that the book is well, and often entertainingly written.
Although some of the content is explicitly targeted at code built in full-blown object-oriented languages (the language used throughout is Java), it doesn't prove to be a hindrance to VB programmers like myself.
This book may fall slightly behind "Code Complete" in my list. Which would only make it the second best development book I've ever read (but it's the first one I felt like posting a review on).
20 of 22 people found the following review helpful
on 21 December 2000
This book is simply great !! It's definately the most useful book I've read since "Design Patterns".
It has an easily read and also sometimes quite amusing text, UML diagrams when necessary, and of course, VERY GOOD CONTENT !!! In short Refactoring is about turning badly designed and written code into well designed and written code, without breaking the program. If you liked read "Design Patterns" (Gamma et al.) you love this one as well. It's structured in much the same way.
The content covers
* WHY + WHEN to refactor
* HOW + WHAT to refactor
* A very good chapter on unit testing with JUnit (Open Source, by Eric Gamma (Design Patterns) and Kent Beck (Extreme Programming) )
* A thorough catalogue of different refactorings you can do to improve the design and readability of your code.
1 of 1 people found the following review helpful
on 13 December 2008
When I first read this book it described a whole lot of practices that I'd been following for years, I just hadn't call it refactoring. I'd find some piece of code that didn't feel right and then I'd tinker with it to improve it. I'd rename variables and methods and rearrange stuff and so on until I felt it was right. I just didn't have a vocabulary to describe what I was doing.
As with other classics the situations and methods that are described here are now considered obvious and simple by many, but that wasn't always the case. This book defined the terms that are now in common use, the code smells, the refactorings, even the word itself. It has provided modern software development with a knowledge and understanding that code isn't developed perfect the first time around, that it is ok to improve it and that it can be done in a safe and controlled manner.
Every developer should read this book at least once. Personally it is one the books that I always keep with me when working.
2 of 2 people found the following review helpful
on 14 November 1999
I found this book superb. It reinforces a number of techniques I had been using and introduces a load more. It takes away that 'guilt' feeling you often have when doing a re-design of existing code and gives you the tools to improve the code greatly. It is well written and each method has a small description, a small example and cross references to other methods which makes it perfect as a reference.
1 of 1 people found the following review helpful
on 13 July 2009
As someone from a procedural background, i've read books on OOP and tried to embrase it into my work but never really saw the point. This book has caused me to change my view of OOP entirely. At the time of reading this book i found myself needing to edit some old code i'd written, as is often the case the old code had grown uglier and uglier the more bits that got added to it, with lots of nested conditionals and a huge switch statement. With the help of what i learnt from this book, i converted the old code to a class heirarchy and reduced the amount of code by 500%, making it far easier to understand, and then add new features too.
I'd recommend this book to anyone who want's to write cleaner code that's easier to maintain. Although the examples are in Java, it's easy to grasp the principles and apply them to PHP.
I just wish i'd read this years ago, as i now want to rewrite everything i've ever done.
on 3 February 2014
A widely regarded classic in the industry, and you can see why.
The first section presents a large refactoring exercise applied to a little movie rental application, which ends up producing a very elegant solution when compared with the original. This is really like the Gang of Four book in that respect, where in the first sections of their book, they present their patterns applied to an example application, to produce a very elegant design. This isn't really surprising, since I'm sure I read Martin saying that he regards GoF as the best technical book of all time.
The first sections of the book are really about advocating a fundamentally different mindset towards refactoring. They are suggesting it's not something you should do just when something is broken or in a mess, but rather on a continuous basis, taking lots of little small steps to make your codebase easier to understand. The book details that this is something you're only really free to do if you have a rigorous test suite to tell you that you haven't broken anything, so there is a section on building a test suite. Interestingly, this book pre-dates Kent Beck's TDD book by a few years, and Beck contributed a lot to the book. There is also a section pointing out 'code smells' that should motivate refactoring; quite nicely, this is summarised in a table at the back of the book, which includes which refactorings you can apply to specific code smells. I actually have to confess that I skipped the section on building the test suite, since I'm a hardcore TDD developer and am already convinced about the merits of that, and didn't feel that it was worth investing my time in.
The next several sections of the book are more reference material. Again, just like the GoF book, each of the refactorings are presented as a pattern style library. As a result, this section of the book was a little harder to get through, as all of the examples that accompany the refactoring are fairly trivial (but you can completely understand the reasoning for that), so I sometimes found my attention a little bit waning.
Post library, there are sections on larger refactorings and refactoring tools, then a pretty large guest section by William Opdyke. To be honest, I didn't really feel like I took much away from the Opdyke section. It went into a lot of detail about refactoring tools and some of the dangers associated with refactoring in C++, due to the complexity of the language. I also just skimmed the section on the tools, since these are things that are quite commonly becoming integrated into the IDE these days.
It's clear this book was highly influenced by the GoF book. However, one aspect in which I think Fowler is superior is in his writing style. It's far less verbose and actually quite funny at times, which makes the book much more enjoyable to read.
Finally, Kent Beck writes a short summary, talking about how the book is only the beginning of the refactoring journey. That resonates quite a lot, as you get the feeling while reading the book, that the real value of it is going to be in continuously coming back to it in your daily work. Trying to look out for the code smells, then consulting the reference library and summary at the back, to aid you in going about eliminating them.
It's more than a decade old, but it's still brimming with insights that continue to apply. The examples use Java, but you can clearly see the concepts apply to any object oriented language.
15 of 18 people found the following review helpful
on 29 June 2006
I'd advise people to ignore the negative reviews for the following reasons:
1) People now talk about specific refactorings so, like design patterns, you need to know the names.
2) It was never supposed to teach you good design. If you want to learn that there are good books out there (including by Craig Larman and Robert C. Martin).
3) Some of it is basic but you can ignore that stuff if you want to, and when your doing some of the more complicated refactorings they could well be useful.
4) As Martin Fowler points out you don't need to read it cover to cover, in fact he advises you use it as a reference.
What this does teach you is how to iteratively improve bad code, something every developer needs to be able to do. In any case its valuable to read about the code smells, the reasons for needing to do specific refactorings and to read the examples.
Also if you want more advanced concepts I'd recommend "Agile Software Development" by Robert C. Martin and "Refactoring to Patterns" by Joshua Kerievsky which both build on this work.
1 of 1 people found the following review helpful
on 13 January 2000
Perhaps that's a little strong, but this book is first rate. I had the good fortune to pick it up just when I joined a project with a lot of legacy code, but not much legacy design. At the same time, the team members felt like they were sinking in a sea of shifting requirements. Fowler addresses this common scenario with usable, practical advice for incrementally improving the design while continuing to meet deadlines.