Status
Available
Call number
Description
Refactoring is about improving the design of existing code. It is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. With refactoring you can even take a bad design and rework it into a good one. This book offers a thorough discussion of the principles of refactoring, including where to spot opportunities for refactoring, and how to set up the required tests. There is also a catalog of more than 40 proven refactorings with details as to when and why to use the refactoring, step by step instructions for implementing it, and an example illustrating how it works The book is written using Java as its principle language, but the ideas are applicable to any OO language.… (more)
Publication
Addison-Wesley Professional (1999), Edition: 1, 431 pages
Similar in this library
ISBN
0201485672 / 9780201485677
UPC
785342485677
Collection
Language
Original language
English
Original publication date
1999
Physical description
9.25 inches
User reviews
LibraryThing member akbibliophile
If you write any code at all, anywhere, read this book. Refactoring should be an integral part of all coding efforts, and this book does a marvelous job of conveying the mechanics and theory of such things through clear prose and many examples.
LibraryThing member euang
Want to know how to be a better software developer?: Then read this book - it contains great tips and hints for how to be a better developer by making your code (or someone else's code) more easily maintainable. For example
> Remove duplicated code
> Write smaller classes "Do one thing and do it
> Only expose methods that need to be exposed
> re-write complicated expressions by introducing temporary variables with names that explain the purpose
and so many others. Particularly great for those left maintaining code written by someone else who thought a class containing 2,500 lines of code is fine.
> Remove duplicated code
> Write smaller classes "Do one thing and do it
Show More
well" > Only expose methods that need to be exposed
> re-write complicated expressions by introducing temporary variables with names that explain the purpose
and so many others. Particularly great for those left maintaining code written by someone else who thought a class containing 2,500 lines of code is fine.
Show Less
LibraryThing member Murdocke23
Very well laid out book. Although it's not a 'read cover to cover' book, the discussions and examples are easy to follow. The first few parts discuss how refactoring is applied and used. the second half, the bulk of the book, covers specific refactorings by category in a templated format. Good
Show More
reference for those first approaching refactoring or those doing less familiar ones trying something. Show Less
LibraryThing member IvanIdris
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
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.
“Refactoring: Improving the
Show More
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.
Show Less
LibraryThing member lorin
Refactoring is the act of restructuring source code without changing its behavior: you refactor the code so that it is easier to modify in the future. Fowler describes a number of different kinds of refactorings, with explicit instructions on how to apply these refactorings.
LibraryThing member momander
This book literally changed overnight the way I write software. The author says we write code primarily for other humans, not for computers. I have heard it before, but this book made me believe it. It doesn't stop there; the author then walks you through exactly how to write code that is easier to
Show More
read. Looking back at my own code, if it's hard to follow, it's from before I read this book. If it reads like a novel, it's from after. Show Less
LibraryThing member brikis98
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
Finally, the exclusive focus on java and OO makes sense, but misses much of the power of functional programming, which removes the need for some types of refactoring entirely. Also, it's a somewhat old version of Java, so the content can feel a little dated.
Overall: an important book to get a sense of refactoring, but the examples leave a lot to be desired.
Good quotes:
With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
It reminds me of a statement Kent Beck often makes about himself, "I'm not a great programmer; I'm just a good programmer with great habits."
A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.
Cons: the code smells section is great, but has no actual code
Show More
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 teaching aids. I think walking through a few medium sized examples, as in the first chapter, would've been more effective. Finally, the exclusive focus on java and OO makes sense, but misses much of the power of functional programming, which removes the need for some types of refactoring entirely. Also, it's a somewhat old version of Java, so the content can feel a little dated.
Overall: an important book to get a sense of refactoring, but the examples leave a lot to be desired.
Good quotes:
With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
It reminds me of a statement Kent Beck often makes about himself, "I'm not a great programmer; I'm just a good programmer with great habits."
A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.
Show Less
LibraryThing member jsburbidge
This is the book that moved refactoring from the focus of a narrow community to a general concept. Illuminating, well-written, and helpful, it strikes an effective balance between the concrete and the abstract. Any OO developer should have this on a shelf beside Design Patterns, with which it is
Show More
nearly contemporary. Show Less
LibraryThing member pgSundling
We're spoiled now that a modern IDE like Eclipse has so many build in refactoring tools, but this was a pivotal book in programming.
LibraryThing member scottjpearson
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
Some of this book is incredibly tedious. It details how to change code from one format to another. It's work that I let my fingers do more of - and my brain less of! But the book also frames how to do this work and why it is so important. It ties together intellectual "loose ends" which might not be tied together by the programmer who simply dives "head first" into the project.
Fowler writes in tandem with a research seminar at the University of Illinois who have pioneered object-oriented techniques in Smalltalk and then Java and C . They tackle the concepts of refactoring more than how to tackle the specifics of coding in a language. I prefer their theoretical approach to more common approaches drenched in technical lingo and programming tools. This book was worth its time.
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
Show More
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 "beneath the surface" of skills that I acquire; this book has indeed enlightened my mind to details of what is going on in my code rewrite.Some of this book is incredibly tedious. It details how to change code from one format to another. It's work that I let my fingers do more of - and my brain less of! But the book also frames how to do this work and why it is so important. It ties together intellectual "loose ends" which might not be tied together by the programmer who simply dives "head first" into the project.
Fowler writes in tandem with a research seminar at the University of Illinois who have pioneered object-oriented techniques in Smalltalk and then Java and C . They tackle the concepts of refactoring more than how to tackle the specifics of coding in a language. I prefer their theoretical approach to more common approaches drenched in technical lingo and programming tools. This book was worth its time.
Show Less
LCC
QA76.R42 F69