Goodreads helps you keep track of books you want to read.

Start by marking “Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series (Fowler))” as Want to Read:

Other editions

Enlarge cover

Rate this book

Clear rating

1 of 5 stars 2 of 5 stars 3 of 5 stars 4 of 5 stars 5 of 5 stars

Open Preview

Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

(Addison-Wesley Object Technology Series)

Martin Fowler

4.25 · Rating details · 7,154 ratings · 292 reviews

Your class library works, but could it be better? Refactoring: Improving the Design of Existing Code shows how refactoring can make object-oriented code simpler and easier to maintain. Today refactoring requires considerable design know-how, but once tools become available, all programmers should be able to improve their code using refactoring techniques.

Besides an introd

...more

Get A Copy

Kindle Edition, 448 pages

Published November 20th 2018 by Addison-Wesley Professional (first published January 1st 1999)

More Details... Edit Details

Friend Reviews

To see what your friends thought of this book, please sign up.

Reader Q&A

To ask other readers questions about Refactoring, please sign up.

Lists with This Book

This book is not yet featured on Listopia. Add this book to your favorite list »

Community Reviews

Showing 1-30

Average rating 4.25 ·

Rating details

· 7,154 ratings · 292 reviews

More filters

Sort order

Start your review of Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series (Fowler))

Jan 27, 2016 Jesse Buss rated it liked it · review of another edition

Overall I was disappointed in this book. Modern tools and IDE's have removed nearly all of the pain points that are laid out in this book, which made reading annoying and tiresome. I skipped the "Mechanics" section of every single refactor because they are just not relevant in 2016. Your compiler and IDE will tell you every thing you need to know in nearly all cases.

That being said the content is good, albeit very basic. I would recommend this to someone who is just out of college or with littl ...more

flag 13 likes · Like · see review

Jan 22, 2012 Ivan Idris rated it it was amazing · review of another edition

Refactoring is the process of rewriting software, without changing the way it functions, in order to improve its readability, testability or maintanability. A book has been written on the subject by Martin Fowler. Some of the chapters were written by other people.

“Refactoring: Improving the Design of Existing Code” is focused on OO programming (lots of Java examples) and Agile practices. It is setup as a catalog of refactoring techniques. Each page dedicated to a refactoring is clearly marked, s ...more

flag 12 likes · Like · see review

Mar 08, 2010 David Workman rated it liked it · review of another edition

Shelves: books-i-read-in-2010, software-development, good-practice

While this book is more of a reference book than a book to read through a memorise (and I intend to use it as such in the future), this book is well worth having for software engineers looking to improve their practices. Even if you don't subscribe to Martin Fowler's 'lots of small methods and classes' style of programming (and I admit, it takes some getting used to), the techniques in this book are still useful and applicable to any software project.

The book consists mainly of a catalog of ref While this book is more of a reference book than a book to read through a memorise (and I intend to use it as such in the future), this book is well worth having for software engineers looking to improve their practices. Even if you don't subscribe to Martin Fowler's 'lots of small methods and classes' style of programming (and I admit, it takes some getting used to), the techniques in this book are still useful and applicable to any software project.

The book consists mainly of a catalog of refactorings. These can be thought of as a 'toolbox' for a programmer looking to clean up their code and improve the code's design, with each refactoring giving a description of how to apply it and a rationale as to when you may wish to. The tail end of the book consists of some large-scale refactorings which are much less mechanical and more hazy due to their much larger scope, and some chapters written by proponents of refactoring, including the renowned Kent Beck (of XP and Smalltalk fame).

In a manner very similar to the GoF Design Patterns book, the refactorings are grouped into sections of similar functionality, and most of the refactorings have an inverse refactoring (extract method has an inverse of inline method, there is both push-up hierarchy and push-down hierarchy for fields and methods, and so on), which are useful in different circumstances. This aids the book as a reference book, and many refactorings also refer to other refactorings within the book as potential followups or re-use them as smaller sub-sets of a larger refactoring (such as extract superclass involving pushing methods and fields up the class hierarchy).

Overall, the book is worth a read-through to familiarise yourself with the content, and keeping close at hand for if you need to remember the details of a specific refactoring. The writing is clear and concise and the refactorings are mostly self-contained so you don't need to go searching over many sections to find all the details. A solid, although not exactly thrilling, book and definitely a foundation for programmers looking to improve their coding skills. ...more

flag 7 likes · Like · see review

Apr 27, 2019 Johnny rated it it was amazing · review of another edition

The second edition of the classic Refactoring book by Martin Fowler is more than just an update. It switched from Java to JavaScript for most of the examples, what lead to many renames of refactorings (for example: extract function instead of extract method). Most of the classical refactorings are still there and it had space for new ones like Split Phase – one practice I found by myself and now can refer to using a name. This tradition of giving names to practices around refactoring is continue ...more

flag 5 likes · Like · see review

Jan 31, 2012 Andreea rated it really liked it · review of another edition

If you are interested in improving and maintaining the quality of your code this book should be on your reading list. It is not the kind of book you read once and forget about it. When you are doing refactoring it’s always recommended to come back and check the categories explained in it.

What I really enjoyed is that it confirmed some of the ideas I already had about software development. On the first hand you should have a robust test suite in order to be certain that refactoring didn’t change ...more

flag 3 likes · Like · see review

Feb 07, 2019 Ehsan Gazar rated it it was amazing · review of another edition

This book is not just for refactoring, it's for understanding how professional are thinking about their code. You can use these methods even in writing the first line of your code.

This is one of the books that every developer should read to transform his knowledge to be in more readable and flexible code.
...more

flag 3 likes · Like · see review

Apr 09, 2020 Ashkan Entezari rated it really liked it · review of another edition

Refactoring is definitely an educational read for any programmer. It covers many areas of refactoring from why we need it to how we should do it and get it done. The only regret that I have right now is reading the first edition of this book (+20 years old!) while there was a second edition which was published 2 years ago. When I read the change-log, it didn't seem like very different but as soon as I picked-up the book I realized how outdated it is in some parts. There are tons of discussions a Refactoring is definitely an educational read for any programmer. It covers many areas of refactoring from why we need it to how we should do it and get it done. The only regret that I have right now is reading the first edition of this book (+20 years old!) while there was a second edition which was published 2 years ago. When I read the change-log, it didn't seem like very different but as soon as I picked-up the book I realized how outdated it is in some parts. There are tons of discussions around how to make sure our refactoring doesn't break the program and at the end there is a chapter dedicated to refactoring tools (apparently only available for Smalltalk at the time) and how we need it for Java and other programming languages. I was reading all these while knowing these days all IDEs have these tools integrated in them and for example I never worry about changing a method name!
But other than this, it was very educational and I think developers can benefit from it.

The Main Take-aways:
- It modularizes refactoring: defines categories of all the common small refactorings and assigns a name for each. Then it defines bigger refactorings as combination of these smaller, standard refactorings.
- This list of refactorings can be studied to better understand code smells and what we can do to fix them (or avoid them in the first place)
- a piece of software is never perfect and its lifetime it should always evolve and change. We can never get it all right in the first place so we should incorporate refactoring in our day-to-day programming. We should not think of it as waste of time but as an essential part of perfecting our software. It gives us a second chance to take another look at the program and fix the issues we couldn't see in the first place.
- Refactoring should be done in small steps and ideally these steps shouldn't get done all in one sitting. We should do a few small steps here and there as we develop and maintain our programs.
- After each step we should run the tests to make sure we haven't broken anything. If we are missing tests, we should and them first and then think about refactoring that part. ...more

flag 2 likes · Like · see review

Oct 19, 2020 Ahmad hosseini rated it it was amazing

Shelves: software-engineering, programming

At the beginning of the book, Martin Fowler states:
“My aim is to show you how to do refactoring in a controlled and efficient manner. You will learn to refactor in such a way that you don’t introduce bugs into the code but methodically improve its structure.”
Well, he has done it perfectly.
There are a lot of #refactoring methods in the book that can inspire you to write better #code and improve the structure of your #software. Some of them are complex and some of them are so simple that maybe you ...more

flag 2 likes · Like · see review

Mar 19, 2019 Damian rated it it was amazing · review of another edition

You hear something about refactoring and you want to see what it is ?
You want to make your code better but don't know how to do it ?

If your answer is yes, then this book is for you.
Martin Fowlers 'Refactoring' is in my opinion the best book about this subject.

Author describes many refactoring techniques and explain how and when to use them.
Each technique has it's own example write in javascript - code is very easy to understand
and you won't have any problems to apply it in your language of choic ...more

flag 2 likes · Like · see review

Dec 04, 2016 Steliyan Stoyanov rated it it was amazing · review of another edition

Shelves: tech

This book is a must-read for every software developer. I would personally recommend it to my team members.

I totally agree with Martin and his vision that the changes should be incremental. I think everyone that tried a "complete rewrite" at some point failed or at least achieved unsatisfactory results. Maybe they didn't completed in time or didn't achieve the expected results.

The most important aspect that is emphasized in the book is that you should apply refactoring when you need to, not just ...more

flag 2 likes · Like · see review

Mar 25, 2020 Mengyi rated it it was amazing · review of another edition

Biggest takeaway is to take really small steps when refactoring, which the book demonstrated a lot with detailed examples. A lot of times I felt uncomfortable during refactoring, but now I know it's because that I cut corners and didn't take small enough steps.

The book also "refactors to patterns" a lot, which I found helpful reading immediately after the design pattern book. ...more

flag 1 like · Like · see review

Jan 25, 2019 Steve Fenton rated it it was amazing · review of another edition

What I like most about this book is that many of the refactorings are accompanied by an inverse equivalent. Like the GoF book on patterns, the idea behind the library is to commit the existence of patterns to memory, but refer back to the library when you want to apply one.

flag 1 like · Like · see review

Jun 08, 2020 Jeroen De Dauw rated it it was amazing · review of another edition

Shelves: non-fiction, software, never-finished

Great introductory book to the topic for people not already nose deep into software design.

flag 1 like · Like · see review

Nov 25, 2019 Thang rated it really liked it · review of another edition

It's more like a reference than a book, so it's a bit dry to read. ...more

flag 1 like · Like · see review

Mar 05, 2017 Aleksander Meterko rated it really liked it · review of another edition

A solid book for a developer which contains a number of so-called "code smells", which should tell you that this specific piece of code needs to be refactored, along with techniques to achieve this result. Although these techniques seems outdated as modern IDEs are able to make most of these refactorings automatically for you (and these automation is described in Chapter 14) it is still good to know when to perform these refactorings.

This book may be read both as a reference guide (it has conven ...more

flag 1 like · Like · see review

Feb 27, 2019 Costin Manda rated it really liked it · review of another edition

Shelves: owned

It was long overdue for me to read a technical book and I've decided to go for a classic from 1999 about refactoring, written by software development icons as Martin Fowler and Kent Beck. As such, it is not a surprise that Refactoring: Improving the Design of Existing Code feels a little dated. However, not as much as I had expected. You see, the book is trying to familiarize the user with the idea of refactoring, something programmers of these days don't need. In 1999, though, that was a breakt It was long overdue for me to read a technical book and I've decided to go for a classic from 1999 about refactoring, written by software development icons as Martin Fowler and Kent Beck. As such, it is not a surprise that Refactoring: Improving the Design of Existing Code feels a little dated. However, not as much as I had expected. You see, the book is trying to familiarize the user with the idea of refactoring, something programmers of these days don't need. In 1999, though, that was a breakthrough concept and it needed not only explained, but lobbied. At the same time, the issues they describe regarding the process of refactoring, starting from the mechanics to the obstacles, feel as recent as today. Who didn't try to convince their managers to allow them a bit of refactoring time in order to improve the quality and readability of code, only to be met with the always pleasant "And what improvement would the client see?" or "are there ANY risks involved?" ?

The refactoring book starts by explaining what refactoring means, from the noun, which means the individual move, like Extract Method, to the verb, which represents the process of improving the readability and quality of the code base without changing functionality. To the defense of the managerial point of view, somewhere at the end of the book, authors submit that big refactoring cycles are usually a recipe for disaster, instead preaching for small, testable refactorings on the areas you are working on: clean the code before you add functionality. Refactoring is also promoting software testing. One cannot be confident they did not introduce bugs when they refactor if the functionality is not covered by automated or at least manual tests. One of the most important tenets of the book is that you write code for other programmers (or for yourself), not for the computer. Development speed comes from quickly grasping the intention and implementation when reading, maintaining and changing a bit of code. Refactoring is the process that improves the readability of code. Machines go faster no matter how you write the code, as long as it works.

The book is first describing and advocating refactoring, then presenting the various refactoring moves, in a sort of structured way, akin to the software patterns that Martin Fowler also attempted to catalog, then having a few chapter written by the other authors, with their own view of things. It can be used as a reference, I guess, even if Fowler's site does a better job at that. Also, it is an interesting read, even if, overall, it felt to me like a rehearsal of my own ideas on the subject. Many of the refactorings in the catalog are now automated in IDEs, but the more complex ones have not only the mechanics explained, but the reasons for why they should be used and where. That structured way of describing them might feel like repeating the obvious, but I bet if asked you couldn't come up with a conscious description of the place a specific refactoring should be used. Also, while reading those specific bits, I kept fantasizing about an automated tool that could suggest refactorings, maybe using FxCop or something like that.

Things I've marked down from the book, in the order I wrote them down in:
- Refactoring versus Optimization - Optimizing the performance or improving some functionality should not be mixed up with the refactoring of code, which aims to improve readability of code while preserving the initial functionality. Mixing them up is pitting the two essential stages of development one against the other.
- Methods should use their data of their own object - one of the telltales of need to refactor is when methods from an object use data from another object. It smells like the method should be moved in the responsibility of that other object.
- When it is easy to refactor, choose a simple design - Of course the opposite is true, as well: when you know it will be hard to refactor a piece of code, try to design it first. If not, it is better to not add unnecessary complexity. This is in line with the KISS concept.
- Split your application into self encapsulated parts - One of the ways to simplify refactoring is to separate your application into bits that you can manage separately. If you didn't design your application like that, try to first split it, then refactor.
- Whenever you need to write a comment, consider extracting a method with a meaningful name - or renaming methods to be more expressive.
- Consider polymorphism when seeing a switch statement - Now that is an interesting topic in itself. Why would polymorphism help here? How could it be simpler to understand than a switch/case statement? The idea behind this is that if you have a switch somewhere, you might have it somewhere else as well. Instead of taking decisions inside each method, it is better to split that behaviour in separate classes, each describing the particular value that the switch would have operated on.
- Test before refactoring - this would have been drilled in your head already, but if not, the book will do that to you. In order to not add faults to the program with the refactoring, make sure you have tests for the existing functionality, tests that should pass after the refactoring process, as well.
- The Quantity pattern - Review the Quantity pattern in order to improve readability and encapsulate simple common actions performed on specific types of units.
Split conditionals into methods - in other words try to simplify your conditional blocks to if conditionMethod() then ifMethod() else elseMethod(). It might seem a sure way to get to a fragmented code base, with small methods everywhere, but the idea is sound. A condition, after all, is an intention. Encapsulate it into a well named method and it will be very clear what the programmer intended. Maybe the same method will be used in other places as well, and then, using polymorphism, one can get rid of the conditional altogether.
- Use Null objects - an interesting concept that I haven't even considered before. It is easy to recognize the need for a Null object when there are a lot of checks for null. if x==null then something() else x.somethingElse() would be turned into a simple x.something() if instead of null, x would be an object that represents empty, but still has attached behavior. An interesting side effect of this is that often the Null object can be made an immutable singleton.
- Code inside Assertions always executes - This is a gotcha I found interesting. Imagine the following code: Assert.IsTrue(SomeCondition()) Even if the Assert object is designed to not execute anything in Release mode, only compiled in Debug, the method SomeCondition() will execute all the time. One option is to use an extra condition: Assert.IsTrue(Assert.On&&SomeCondition()) or, in C#, try to send an expression: Assert.IsTrue(()=>SomeCondition())
- Careful when replacing method parameters with parameter object in parallel processing scenarios - Which nowadays means always. Anyways, the idea is that old libraries designed for parallel processing used large value parameter lists. One might be inclined to Introduce Parameter Object, but that introduces a reference object that might lead to locking issues. Just another gotcha.
- Separate Modifier from Query - This is a useful convention to remember. A method should either get some information (query) or change some data (modifier), not both. It makes the intention clear.

That's about it. I have wet dreams of cleaning up the code base I am working on right now, maybe in a pair programming way (also a suggestion in the book and a situation when pair programming really seems a great opportunity), but I don't have the time. Maybe this summary of the book will inspire others who have it. ...more

flag Like · see review

May 01, 2014 Yevgeniy Brikman rated it liked it · review of another edition

Pros: presenting refactoring as a regular part of the development process is an important step forward. The example at the start of the book is a great demonstration if why this stuff matters. Nice to systematically catalog code smells.

Cons: the code smells section is great, but has no actual code examples. The chapters that go through the refactoring moves are better, but having each one isolated makes it boring to read. The big refactoring chapters are only UML diagrams, which are not good te ...more

flag 1 like · Like · see review

Apr 18, 2012 Nick rated it really liked it · review of another edition

I was having a great time reorganizing and hopefully improving some Java at work, and a coworker had mentioned this book. Good stuff. I didn't read through the whole reference section, but took a quick look at some. It seems like the IDE I was using (IntelliJ) had a bunch of refactorings (not sure what the overlap is with this catalog) available as keyboard shortcuts, basically. But it's still fun to read about. Unfortunately, I got this book approximately the same week I shifted off Java develo ...more

flag 1 like · Like · see review

May 19, 2015 Katherine rated it really liked it · review of another edition

Shelves: programming

Finally finished this, long after the book club for it was over! This is a classic, which means there are both really good pieces of wisdom in here as well as concerns that don't need to be worried about so much anymore with more modern tools and text editors. The majority of the book is kind of a reference of refactoring "recipes" with checklists to go through to make sure you haven't missed something--time will tell if I end up using that reference portion. The descriptions and motivations for ...more

flag 1 like · Like · see review

May 22, 2017 Mahmoud Tantawy rated it it was amazing · review of another edition

Good way to end a year!
A must-read reference for every developer, not only ones dealing with legacy code but ones starting new project to save the project on the long-run.

The book is well written, provides samples, examples, diagrams, steps to follow, side-notes, commentary, and basically everything you would need to fully understand a refactoring method.

While the book doesn't provide revolutionary solutions to perform refactoring (you shouldn't perform major refactoring in one step anyway), a l ...more

flag 1 like · Like · see review

Mar 09, 2009 Daniel rated it it was amazing · review of another edition

Shelves: work

The best programming book I've read in a long time.

There are a lot of design and analysis books but not a lot of programming books. I would gladly read anything from Fowler. It's so simple of a concept but it goes against a lot of 'common sense'. Essentially, don't over design. Don't spend too much time in design and analysis that you've been told to do based on the wrong assumptions of the waterfall model (which never worked).

Kent's book on Test-driven Development is a great companion to this ...more

flag 1 like · Like · see review

Sep 09, 2019 Tien Nguyen Van rated it really liked it · review of another edition

This book can give you a motivation to start refactoring & how to do it the right way.
From my perspective, this book 70% like a catalog to look up when you have a case & need to refactor it.
I can't remember all of the patterns, but I can index it whenever I don't have any idea how to refactor it.
One more thing that around the pattern which covers by this book good focus for OOP than others. I didn't like this point too much. ...more

flag 1 like · Like · see review

Sep 11, 2014 Ricardo Cavalcanti rated it it was amazing · review of another edition

Shelves: coding-practice, must-reads

This book represents one of the building blocks of good programming. Most of the examples are in java, and most of the techniques are already implemented by IDE such as IntelliJ. Still, the ideas can be applied in any programming language, with or without an IDE.

flag 1 like · Like · see review

Feb 02, 2016 Fernanda Martins rated it really liked it · review of another edition

Very dense book. There's a lot of techniques about refactoring. It's a bit intense so I recommend not reading everything at once like I did. ...more

flag 1 like · Like · see review

Aug 04, 2019 Simon Booth rated it liked it

Good in its day

This is the book that introduced the concept of refactoring to the wider software engineering community. A refactoring is a change to the structure of code that does not change its functionality. Prior to this the prevailing wisdom was "if it ain't broke don't fix it", and whilst this is still a sensible principle in general most programmers know that code can be broken even when it produces the correct output. Refactoring the code can help to fix those less tangible problems - ma Good in its day

This is the book that introduced the concept of refactoring to the wider software engineering community. A refactoring is a change to the structure of code that does not change its functionality. Prior to this the prevailing wisdom was "if it ain't broke don't fix it", and whilst this is still a sensible principle in general most programmers know that code can be broken even when it produces the correct output. Refactoring the code can help to fix those less tangible problems - making code easier to understand, modify and maintain.

In the 20 years since the first edition this has become an uncontroversial point and "refactoring" has entered the daily lexicon of the software engineering discipline. Surely time for an update to the classic text on the subject to bring it up to date with all the learning that 20 years of widespread practise have revealed!

Unfortunately it seems that there isn't much new to say. The refactoring techniques have been shuffled around a bit, sometimes consolidated or split, but they all seem very familiar. They are now so familiar that they seem trivial in fact, so obvious they barely need mentioning. Whilst there is value in establishing a common lexicon for these common operations, the detailed step by step examples become a chore to read through because they are so obvious.

One of the major changes in this anniversary edition is that the examples in Java from the first edition (it was fashionable at the time) have been rewritten in Javascript (it was fashionable at the time). This is a questionable choice... Javascript is idiosyncratic, and a weakly typed language does not illustrate the form of some of the techniques described well. So many of the examples are qualified with "because javascript..." or "in a statically typed language..." that it must have occurred to the author that the book would be clearer (and probably shorter) if the examples had been written in a language more suitable to what they were intended to illustrate.

Most of the examples boil down to making small, incremental changes and then running your comprehensive set of tests (which take a few seconds to run) to make sure you didn't make a mistake. Fine if you're working on some small, isolated piece of code with unit tests accessible at a keystroke... Less helpful when you're working with part of a legacy system that takes 15 minutes to build and 30 to run through its tests (if they exist). Unfortunately the latter are where refactoring is probably most needed.

The book is worth adding to your library and at least skimming to pick up some patterns and terminology if you're new to programming. You might occasionally even find yourself consulting it as a reference for how to do a refactoring, though the answer is probably "in the obvious way".

The author should rightly be proud of the fact that his original text was so influential that 20 years later it is hard to imagine that there was a time when it needed to be written ;-) ...more

flag Like · see review

Feb 13, 2019 Jean Tessier rated it it was amazing · review of another edition

Shelves: software

An update to the 1999 classic Refactoring. I still have my autographed copy of the first edition. The original used code examples in Java. This new edition uses JavaScript instead.

I followed Fowler's advice to "read the first four chapters completely, then skip-read the catalog." It's the same approach I used when I read Gerard Meszaros' xUnit Test Patterns. The initial chapters make a case for refactoring and describe the general principles. The remainder of the book is a nice catalog of specif An update to the 1999 classic Refactoring. I still have my autographed copy of the first edition. The original used code examples in Java. This new edition uses JavaScript instead.

I followed Fowler's advice to "read the first four chapters completely, then skip-read the catalog." It's the same approach I used when I read Gerard Meszaros' xUnit Test Patterns. The initial chapters make a case for refactoring and describe the general principles. The remainder of the book is a nice catalog of specific refactorings, each using a clear template.

Many people associate refactoring with the first edition of this book. It is the seminal work on the topic. Therefore, many people credit Fowler for bringing refactoring to the attention of the masses. I did not remember, from reading the first edition, how much Fowler owed to Kent Beck. In the introduction, he credits Beck for introducing him to refactoring. It is very interesting to watch the interplay between these two strong players of contemporary software development.

One constant concern is the importance of naming. Many refactorings deal with putting good names on programming artifacts.

Throughout the book, Fowler is always trying to find the balance between doing the right thing in general and doing the right thing for the particular case. Above all, he values flexibility and being able to adjust to the circumstances. This is why some refactorings have an inverse, so Fowler can modify his code back and forth, as dictated by his understanding of the moment.

This flexibility shows up again in the topic of testing. Some authors advocate lots of tests and maximize coverage, going so far as to fail the build if coverage gets too low. This is a mindless application of testing and its strongest supporters often use it to mask their own poor skills at coding.
Fowler supports a smarter approach that is more humanistic and tries to maximize the return on the effort invested in testing.

There is a law of diminishing returns in testing, and there is the danger that by trying to write too many tests you become discouraged and end up not writing any. You should concentrate on where the risk is. (p. 98)

Fowler refers to the Law of Demeter as "the Occasionally Useful Suggestion of Demeter" (p. 192).

On a personal note, since I started been programming in Groovy and using closures, I find myself using collection pipelines a lot. I have come to prefer that style of code over the previous, more procedural one. As a result, I really liked the Replace Loop with Pipeline (231) refactoring. ...more

flag Like · see review

Dec 25, 2020 Michael rated it liked it · review of another edition

Shelves: programming

I went into this book with pretty large expectations. I had heard the book was great, but I realize now I never really heard why it was great. The rumor mill just told me that it was the book to read if you wanted to learn refactoring.

Unfortunately, I found myself very disappointed by the book. The first four chapters could be compared to Clean Code in many ways; they introduce some good practices of coding and how to perform a refactoring safely. But beyond that it is just a reference list of a I went into this book with pretty large expectations. I had heard the book was great, but I realize now I never really heard why it was great. The rumor mill just told me that it was the book to read if you wanted to learn refactoring.

Unfortunately, I found myself very disappointed by the book. The first four chapters could be compared to Clean Code in many ways; they introduce some good practices of coding and how to perform a refactoring safely. But beyond that it is just a reference list of all the different types of refactoring. On some level I understand why he went into as much detail as he did, but there were a few that just felt extremely long-winded for how simple they are. I don't really need an example of `rename field`.

But that was another criticism I had about this book; the refactoring difficulty levels were wildly different. Some of the refactoring steps were so simple that any modern IDE can handle it without even pausing (rename field, move declaration, delete unused code), while others were very highly involved changes that could have long reaching impacts across the entire system, most notably "introduce polymorphism". So in terms of the book, renaming a variable is equivalent to introducing a series of classes and polymorphism into your application. Perhaps what the book needs is some sort of difficulty rating, that way I at least get the sense the author realizes not all refactorings were created equal.

Rants about difficult levels aside, this book really does turn into a reference book. It simply lists every refactoring, no matter how trivial, and tells the motivation, process, and an example (or several). That's it. The motivation is almost never more than a paragraph or two, so in terms of hard thinking, you won't be doing much for this book. I would certainly not recommend this book to a programming book club; we found ourselves struggling to come up with topics of conversation at times since everything was so straightforward. And we found ourselves skipping most, if not all, of the examples by the end of the book. It just wasn't worth the time to read how to do the refactoring.

I won't say that the book is bad, because it isn't. And it certainly isn't a bad concept. But I will say it wasn't an exciting book. I didn't learn anything new that I'm excited to implement in my daily programming life. It's like brushing my teeth; it's not fun, it's not exciting, but it's very important to do. ...more

flag Like · see review

Dec 10, 2020 Deane Barker rated it it was amazing · review of another edition

You sort of have to give this five stars, just based on reputation alone. This is one of the great books of computer science.

As the title would imply, it's about fixing the internals of computer programs, without changing how the program functions from the "outside." This is a time-honored task in computer science -- programs get all twisted and crufty over time as they're modified and maintained, and every once in a while you have to straighten things out so you can continue working on them eas ...more

flag Like · see review

Feb 09, 2019 Scott J Pearson rated it liked it · review of another edition

Shelves: software-technology

I picked up this book at the wrong time. The book was so successful that a second edition is due out on November 30, 2018 (less than two weeks from now).

On the other hand, I picked up this book at the right time. At work, my project is in the midst of a refactoring project. I am in the middle of changing PHP code from modular functions to object-orientation. The aim of this transition is to enhance the scalability of the project and ease the writing of documentation. I generally like to peer "be ...more

flag Like · see review

Dec 29, 2020 David Stevenson rated it really liked it · review of another edition

This is a review of the 2nd edition.
While I thought I had a decent knowledge of what refactoring was, having read the first 100 pages of this book, I had to admit to myself that my knowledge had been shallow at best. People in IT do have a tendency to fling terms around loosely, and “refactoring” is one of those terms.
The first part of the book sorts you out in that respect, and also gives you an education about why refactoring is important and also how to go about doing it in your software deve ...more

flag Like · see review

« previous 1 2 3 4 5 6 7 8 9 10 next »

new topic
Discuss This Book

topics	posts	views	last activity
Goodreads Librari...: Second edition is listed as a separate book	2	239	Dec 19, 2018 10:43AM

Readers also enjoyed

See similar books…

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »

Genres

Computer Science > Programming

827 users

Science > Computer Science

285 users

Science > Technology

277 users

Computer Science > Software

220 users

Computer Science > Technical

162 users

Nonfiction

108 users

Computer Science > Coding

83 users

Computer Science > Computers

57 users

Reference

54 users

Science > Engineering

46 users

See top shelves…

About Martin Fowler

Martin Fowler

816 followers

Martin Fowler (b. 1963) is a software engineer, Chief Scientist at ThoughtWorks, and an outspoken advocate for best practices in enterprise software design, particularly in regard to agile software development methodologies, including extreme programming. ...more

Other books in the series

Addison-Wesley Object Technology Series (1 - 10 of 39 books)

Books by Martin Fowler

Patterns of Enterprise Application Architecture

UML Distilled: A Brief Guide to the Standard Object Modeling Language

Analysis Patterns: Reusable Object Models

More…

News & Interviews

Goodreads' Staff Recommends Their Favorite Audiobooks

Listen up, because our colleagues here at Goodreads have some excellent audiobook recommendations for you! Of course, the books they've...

Trivia About Refactoring: Impr...

No trivia or quizzes yet. Add some now »

Quotes from Refactoring: Wie ...

“I’m not a great programmer; I’m just a good programmer with great habits.” — 16 likes

“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.” — 9 likes

More quotes…

See a Problem?

Preview — Refactoring by Martin Fowler

Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

(Addison-Wesley Object Technology Series)

Get A Copy

Friend Reviews

Reader Q&A

Lists with This Book

Community Reviews

new topic
Discuss This Book

Readers also enjoyed

Goodreads is hiring!

Genres

About Martin Fowler

Other books in the series

Books by Martin Fowler

News & Interviews

Trivia About Refactoring: Impr...

Quotes from Refactoring: Wie ...