One of the best software developer books, If you have the challenge of redesign a software application this is the book you need to read but before buy it, make sure the application you are going to refactor has unit-tests, if not as the book mentioned first you need to read: Working Effectively with Legacy Code of Michael Feathers, read this book first and later read this one.
Thank you so much to Martin Fowler.
Enjoy fast, free delivery, exclusive deals, and award-winning movies & TV shows with Prime
Try Prime
and start saving today with fast, free delivery
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club? Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Save on audiobooks.
Hundreds of titles up to 80% off. Listen now
Frequently bought together
$38.59
Get it as soon as Wednesday, Dec 20
In Stock
Total price:
To see our price, add these items to your cart.
Choose items to buy together.
More items to explore
Page 1 of 1 Start overPage 1 of 1
From the Publisher
Refactoring is...
a disciplined way to clean up code that minimizes the chances of introducing bugs. Although it is focused on the code, refactoring has a large impact on the design of systems. It is vital for senior designers and architects, as well as professional programmers, to understand the principles of refactoring and to use them in their projects.
About the author
Follow authors to get new release updates, plus improved recommendations.
Reviews with images
Submit a report
A few common reasons customers report reviews:
- Harassment, profanity
- Spam, advertisement, promotions
- Given in exchange for cash, discounts
When we get your report, we'll check if the review meets our Community guidelines. If it doesn't, we'll remove it.
Sorry, there was an error
Please try again later.Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Reviewed in the United States on September 17, 2023
Reviewed in the United States on January 3, 2023
Reviewed in the United States on July 2, 2023
Reviewed in the United States on October 27, 2023
One of the most popular CS papers ever ("Hints for Computer System Design", 1983) suggests 3-step process about writing code - first, make it work; second, make it right; finally, make it fast". This book, a succinct second edition of a very popular first, is an excellent "show and tell" for the second part.
It has a catalog of "code smells" and an inventory of "refactoring tricks" mapped to each. The first edition had working Java examples. The present one shows JavaScript ones. The examples are real-life but simple enough to not distract from the core - how to simplify the "first version" of code. Apart from the content, the insights that pops out can only be gleaned from years of deep experience. One example, say, most developers encode a "phone number" attribute as string in the first attempt of modeling. Soon enough, one needs to add "spam rules", "blocking number", "area code" etc. That necessitates phone number to be 'refactored' from string (i.e., a primitive type) to its own object model (say, a class called PhoneNumber). The author cheekily refers to the former type of behavior as "stringly typed" variables. Word play is a hallmark of many good engineers I'd worked with, but it is also a phenomenal way to remember things. Humor shortens the retrieval curve.
What I liked most about the book is a broad adoption of "Paracelsus' Maxim" - the difference between a poison and something benign is the dose. Most of the refactoring pattens come in pairs. You can "extract function" from a big one, or "inline function code" if it is short, obvious and singularly used, say. You can "replace parameter with query" or "replace query with a parameter". The only unpaired pattern shows up with large/complex conditionals (say, a switch, or a multiway nested conditional with 'guard clause) - most/all of them are pain to read and should ideally be refactored, say, with "replace conditional with polymorphism". Live book site has 4 more patterns beyond the book.
I found the refactoring patterns could be of three principal dimensions - one, structure -- variable, method, class, conditional; two, usage and locality -- depending on how much they're used and if they are used within/outside the module (class); three, data and mutation -- there is a clear separation between refactoring a data (or, value) object/data passed as value- or reference; separating data (query) from command etc. On top of that, some of the refactoring could be thought of as "helping the original developer" (say, to modularize or DRY better) vs. "helping others who may read the code later".
When I read the first edition years ago, IDEs were not as robust nor opinionated enough about refactoring. These days, majority if not all the refactoring is done by default - one just needs to click to accept, say, extracting a method. It has been a huge time saving and long-term benefit for collaborative work and fits very well within the philosophy of "continuous integration"/Kaizen etc. One could argue that lowers the importance of such book. While the IDE may do the grunt work, key decisioning remains with humans, for now. Especially since most refactoring could appear in polar opposites it is therefore even more important to understand the context - the "why" - which this book brilliantly lays out.
If you have the right 'why', you can bear almost any 'how'
Reviewed in the United States on October 27, 2023
Code is written by humans, executed by machines. Live code is also read by (other) humans for about 10x more than the time it took to write it. This is where "refactoring" comes to play. It is sort of making continuous improvement to code so it is more readable. It is cleaning up cobwebs from the corners.Reviewed in the United States on October 27, 2023
One of the most popular CS papers ever ("Hints for Computer System Design", 1983) suggests 3-step process about writing code - first, make it work; second, make it right; finally, make it fast". This book, a succinct second edition of a very popular first, is an excellent "show and tell" for the second part.
It has a catalog of "code smells" and an inventory of "refactoring tricks" mapped to each. The first edition had working Java examples. The present one shows JavaScript ones. The examples are real-life but simple enough to not distract from the core - how to simplify the "first version" of code. Apart from the content, the insights that pops out can only be gleaned from years of deep experience. One example, say, most developers encode a "phone number" attribute as string in the first attempt of modeling. Soon enough, one needs to add "spam rules", "blocking number", "area code" etc. That necessitates phone number to be 'refactored' from string (i.e., a primitive type) to its own object model (say, a class called PhoneNumber). The author cheekily refers to the former type of behavior as "stringly typed" variables. Word play is a hallmark of many good engineers I'd worked with, but it is also a phenomenal way to remember things. Humor shortens the retrieval curve.
What I liked most about the book is a broad adoption of "Paracelsus' Maxim" - the difference between a poison and something benign is the dose. Most of the refactoring pattens come in pairs. You can "extract function" from a big one, or "inline function code" if it is short, obvious and singularly used, say. You can "replace parameter with query" or "replace query with a parameter". The only unpaired pattern shows up with large/complex conditionals (say, a switch, or a multiway nested conditional with 'guard clause) - most/all of them are pain to read and should ideally be refactored, say, with "replace conditional with polymorphism". Live book site has 4 more patterns beyond the book.
I found the refactoring patterns could be of three principal dimensions - one, structure -- variable, method, class, conditional; two, usage and locality -- depending on how much they're used and if they are used within/outside the module (class); three, data and mutation -- there is a clear separation between refactoring a data (or, value) object/data passed as value- or reference; separating data (query) from command etc. On top of that, some of the refactoring could be thought of as "helping the original developer" (say, to modularize or DRY better) vs. "helping others who may read the code later".
When I read the first edition years ago, IDEs were not as robust nor opinionated enough about refactoring. These days, majority if not all the refactoring is done by default - one just needs to click to accept, say, extracting a method. It has been a huge time saving and long-term benefit for collaborative work and fits very well within the philosophy of "continuous integration"/Kaizen etc. One could argue that lowers the importance of such book. While the IDE may do the grunt work, key decisioning remains with humans, for now. Especially since most refactoring could appear in polar opposites it is therefore even more important to understand the context - the "why" - which this book brilliantly lays out.
Images in this review
Reviewed in the United States on August 16, 2022
Reviewed in the United States on December 15, 2018
Top reviews from other countries
Pete
Not as good as 1st edition
Reviewed in the United Kingdom on September 8, 2023Amazon Customer
Refactoring right is important
Reviewed in Canada on August 10, 2023Whatever Ye. Do
Thoughtful and engaging
Reviewed in the United Kingdom on April 26, 2019