Refactoring (1999) (edit title/settings)

• Rated 0 stars

“One of the best book I ever read.”

• Rated 5 stars

“Landmark work from Fowler. First 100 pages a must read, rest is basically a refactorings catalog.”

• Rated 0 stars

“Although old - timeless guide.”

• Rated 0 stars

“Conclusion: If you do refactorings daily, perhaps skip the book. If not, read chapter 1, perhaps browse through 2 and 12, check whether anything catches your eye in the refactoring catalog table of content, read Kent's closing chapter and return the book to the local museum. Detailed review at http://theholyjava.wordpress.com/2010/11/25/book-review-refactoring-by-martin-fowler/”

• Rated 3 stars

“Solid book, though a bit lengthy. I especially value the first chapter which introduces the concept of refactoring through a hands-on example. By seeing every step in the transformation from a lousy program to a better design, you get a clear view of what refactoring is, how to do it and most importantly: why it's important. I'll use this chapter as a basis for training my colleagues on the matter next week! ”

• Rated 4 stars

“Martin Fowler`s classic, which belongs to every programmers bookshelf. Book starts with describing motivation, history, princibles and mechanics behind refactoring. The following chapters contain large catalog of code smells and their refactorings, each described carefully with title, motivation, mechanics, diagram and (Java) code examples. Even small refactorings (such as rename method) are described. This book works as excellent refactoring reference catalog - totally recommended to agile developers, who practice refactoring as important development technique in their work. ”

• Rated 5 stars

“A must-have reference book always by your side. Most of the static code analyzers and checkstyle lint tools do nothing but automate what the book shares. Eclipse IDE has most of the refactoring task in the book automated. This surely will lead to a new simple , clean & readable code.”

• Rated 3 stars

“Fundamental though was kinda Captain Obvious to me after working with Resharper :)”

• Rated 5 stars

“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, so that you can easily look up a refactoring.

The book was written a decade ago. At that time IDE’s did not support advanced refactorings. Most of the methods described are fully automated in modern IDE’s. This means that you don’t have to follow the text that closely any more.

1. Refactoring, a First Example

The first chapter starts with a simple example. Java code is used throughout the example as well as UML diagrams.

2. Principles in Refactoring

The Why and When of refactoring are discussed. Also we get instructions on what to tell our manager about refactoring. This seems a bit silly to me, since I have never had to explain refactoring to my managers.

3. Bad Smells in Code

“Code Smells” is a frequently used Agile phrase. A phrase I don’t care that much about. Code works or it doesn’t, it can be ugly or unreadable, but it doesn’t smell. The list of “smells” makes sense, however some of the names are downright confusing. For instance, would you be able to tell me what “Refused Bequest” means?

4. Building Tests

This chapter talks about JUnit at length. I am sure you are aware that there are many other unit testing frameworks for programming languages other than Java such as PyUnit. We are told that before you start refactoring, you need to have tests. I think it is more of a chicken/egg dilemma. Sometimes you need to refactor first in order to test. Unit tests and functional tests are mentioned. Integration tests, however are completely ignored. How would you know whether the performance and memory usage of your system remained the same? Clearly, this chapter was written by a software developer, and not by somebody who likes breaking applications, I mean testing applications.

5. Toward a Catalog of Refactorings

Chapter 5 describes the catalog of refactorings to follow. It is the catalog metada in a sense.

6. Composing methods

This chapter is the beginning of the catalog, which forms the “meat” of the book. I am just going to mention a few of the techniques listed in chapter 6.”Extract Method” is one of those refactorings I use on a daily basis. Sometimes things go wrong so we have to do the opposite refactoring “Inline Method”. The author starts using the term “temp” to mean temporary local variables.

7. Moving Features Between Objects

The author admits that he has trouble assigning responsibilities to objects. We are supposed to fix errors with “Move Method”, “Move Field”, “Extract Class” or other refactorings in this chapter.

8. Organizing Data

This chapter discusses a lot of different ways to simplify working with data. For instance, with these refactorings:

Replace Data Value with Object
Replace Array with Object

Also the refactoring “Replace Magic Number with Symbolic Constant” is explained a.k.a “Extract Constant”.

9. Simplifying Conditional Expressions

In my opinion the refactorings in this chapter need to be renamed. Apart from “Decompose Conditional”, which is clear enough. Although “Breaking up Conditional” might have been better.

10. Making Method Calls Simpler

Make method calls simpler by renaming them or replacing long parameter lists by objects. The latter technique could be a problem in concurrent programs. It is common to pass immutable values as parameters. You might not be able to replace them by immutable objects.

11. Dealing with Generalization

Generalization or in OO terms inheritance is a powerful mechanism, that tends to be overused a lot. You can push/pull a method or a field. Inheritance can be replaced by delegation and vice versa.

12. Big Refactorings

In this chapter starts what we can call the “dessert” part. No more simple refactoring recipes. Instead four refactorings that take a considerable amount of time.

13. Refactoring, Reuse and Reality

This chapter is an essay on Refactoring by William Opdyke.

14. Refactoring Tools

IDE’s have come a long way since this book was written. Most of the issues in this chapter are no longer valid.

15. Putting It All Together

This final chapter by Kent Beck is a bit mystical and vague. Those are his own words by the way. Some of the points make sense, but the chapter is written too much in a master talking to an apprentice style.

The book has a list of soundbites at the end. Literally. The fun thing is that you probably have heard or are going to hear a lot of these soundbites. “Refactoring” is a very useful book, albeit too focused on Java. Most recipes would work for another Object Oriented language. I give this book 5 stars out of 5.”

• Rated 5 stars

“Must Read”