Announcing the Second Edition of “Refactoring”(martinfowler.com)
martinfowler.com
Announcing the Second Edition of “Refactoring”
https://martinfowler.com/articles/201803-refactoring-2nd-ed.html
60 comments
But the compelling reason for choosing it over Java is that isn't wholly centered on classes.
That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book.
Perhaps it's my back end bias showing.
That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book.
Perhaps it's my back end bias showing.
Python is amazing for these types of books. Written with the intention in mind, the actual code reads like pseudo-code, and a good percentage of people have interacted with the language at least briefly. Though the latter point is certainly more relevant for JS.
I'm sure the author had his reasons, and there are certainly worse choices in the top dozen languages. (Refactoring... in PHP!)
I'm sure the author had his reasons, and there are certainly worse choices in the top dozen languages. (Refactoring... in PHP!)
From the article:
> Such a language needed to be widely popular, among the top half a dozen in language popularity surveys. It really helps to have a C-based syntax, since most programmers would recognize the basic code structure
You can argue others, but at least this will help you understand why he chose it over many other languages that aren't centered on classes.
> Such a language needed to be widely popular, among the top half a dozen in language popularity surveys. It really helps to have a C-based syntax, since most programmers would recognize the basic code structure
You can argue others, but at least this will help you understand why he chose it over many other languages that aren't centered on classes.
The Refactoring book in Javascript looks like an early April, 1st joke :-)
What I really miss is the integration with the automatic refactoring tools in our IDEs. How would I make a heavy refactoring if I already have a "extract method" in my interface? Would it be the same? Some of the refactorings are easier to automate so are more common in the IDEs. Would are better paths considering what is automated?
What I really miss is the integration with the automatic refactoring tools in our IDEs. How would I make a heavy refactoring if I already have a "extract method" in my interface? Would it be the same? Some of the refactorings are easier to automate so are more common in the IDEs. Would are better paths considering what is automated?
Seems like JavaScript would make sense since there are so many young, inexperienced js developers that stand to potentially benefit from such a book.
Probably it makes sense because it is the most used lang in the world. Everybody has a interpreter on their computers. Also there are more people to buy the book.
I'm asking this from a position of massive ignorance (I'm mostly a backend dev who does the occasional website), but is there any type hinting tooling in the Javascript ecosystem? Python has PEP484 where you annotate types in either comments or docstrings, Ruby has YARD tags used similarly, and smart IDEs can pick up on these and offer decent refactoring tools.
But does anything similar exist in JS land?
But does anything similar exist in JS land?
TypeScript is fast becoming the go-to language for JavaScript with types.
They still didn't manage to put together a usable language. Just try to import your `Foo` class into `Bar` and your `Bar` class into `Foo`. BOOM! It will explode into your face. And this is just a basic thing which should work in a real language.
I will second this. I've seen some people choose FB's Flow as their type checker, but for me, I'm loving Typescript. It has minor problems when it has to use DefinitelyTyped and integrate with other frameworks, but those are minor in comparison to not having it.
Yes, there is JSDoc[1] which allows you to add type annotations in comments, that can then be used by some tool.
The VSCode editor is able to leverage the TypeScript engine even with vanilla JS to automatically infer types and also supports JSDoc. Basically you write vanilla JS, add JSDoc comments here and there when the inference doesn't work as you want and it gives you most benefits of a typed language, without tying yourself to a specific ecosystem (your teammates could be using something else entirely). It works pretty well.
[1] http://usejsdoc.org/
The VSCode editor is able to leverage the TypeScript engine even with vanilla JS to automatically infer types and also supports JSDoc. Basically you write vanilla JS, add JSDoc comments here and there when the inference doesn't work as you want and it gives you most benefits of a typed language, without tying yourself to a specific ecosystem (your teammates could be using something else entirely). It works pretty well.
[1] http://usejsdoc.org/
This is more what I was looking for; the others appear to be supersets of JS.
Flow does this very well. https://flow.org/
I honestly hoped that this was an April fool's joke.
I realise this is an unpopular opinion, but I really didn't like the previous book. Don't get me wrong, I definitely think refactoring is a good thing (in moderation!). But Fowler presented a list of possible refactoring operations, including step by step instructions... for very trivial things.
In the introduction he drew comparisons with GoF design patterns book, saying he wrote it hoping people would refer back to it as they do to that book. Yes, sometimes I need to rename a function or split it in two, but do I really need to dig out a reference book to look up how to do that? And the comparison to design patterns is crazy, those are at a far higher level of abstraction and are correspondingly less obvious (and more interesting).
In the introduction he drew comparisons with GoF design patterns book, saying he wrote it hoping people would refer back to it as they do to that book. Yes, sometimes I need to rename a function or split it in two, but do I really need to dig out a reference book to look up how to do that? And the comparison to design patterns is crazy, those are at a far higher level of abstraction and are correspondingly less obvious (and more interesting).
I never read more than a fraction of the first edition, but I found it valuable. The key idea was that refactoring was a methodical, careful process that consists of steadily taking the code from one working state to another. At the time, refactoring was a dirty word at my company, and people didn’t distinguish it from rewriting code in any arbitrary fashion.
This sounds mostly like the first chapter, which was the bit I enjoyed the most. That was about automated testing, and a whole book about that might've been quite useful.
Automated testing is great, but you can apply the core idea to code without automated tests. The difference is that you have to be even more mechanical and cautious.
In addition to the principles about refactoring, reading a few of the examples helped to drive in how methodical it was.
In addition to the principles about refactoring, reading a few of the examples helped to drive in how methodical it was.
I've found out that in my decades of software engineering that what I take as trivial and simple actually isn't for folks who haven't really delved into it or they are mid or junior level engineers.
I'd rather do skim reading on stuff that I already know than for them to skip over it just in case there was a fundamental issue that was missed (or deemed trivial).
I'd rather do skim reading on stuff that I already know than for them to skip over it just in case there was a fundamental issue that was missed (or deemed trivial).
I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here read the first edition, and what was your impression of it?
One of my biggest lessons from the book is right in the introduction. To paraphrase: "If a change you want to make to the codebase is hard, refactor the codebase until that change is easy, then make the change".
I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.
I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.
This quote is inspired by Kent Beck who coined it while he and Martin Fowler were working together.
> "For each desired change, make the change easy (warning: this may be hard), then make the easy change"[0]
[0] https://twitter.com/KentBeck/status/250733358307500032
Edit: Added a link to his first Tweet containing the quote that I know of.
> "For each desired change, make the change easy (warning: this may be hard), then make the easy change"[0]
[0] https://twitter.com/KentBeck/status/250733358307500032
Edit: Added a link to his first Tweet containing the quote that I know of.
A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time.
Keep those tasks separate.
Keep those tasks separate.
I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.
One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.
This is the approach I try to take. It requires discipline but it has helped on several occasions.
The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.
Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.
The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.
Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.
The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line
At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.
I typically start by adding some test cases or extract code (say as a function/method) add code to test it and keep repeating the cycle. I feel confident with this approach, especially with dynamiclly typed language like Python.
I found it very interesting for being one of the very few books that deals with code as a formal system.
You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries.
The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now.
Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike.
[1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan...
[2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/007...
[3] https://www.amazon.com/Unix-Programming-Environment-Prentice...
You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries.
The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now.
Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike.
[1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan...
[2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/007...
[3] https://www.amazon.com/Unix-Programming-Environment-Prentice...
Would you recommend "Software Tools in Pascal" vs the original?
The original one in written in RATFOR with no structures/records or recursion which make some of the programs more complicated than they should. It easy to find the two versions on Internet.
They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.
They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.
Either. The details aren't especially relevant in either case. I just picked one.
I enjoyed the first edition immensely. Some folks are calling out that most of the refactorings are mainstream, but IDE integration doesn’t mean that it has become common practice or second nature to most engineers.
If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book.
Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference.
The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code.
Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)
If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book.
Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference.
The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code.
Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)
I found it to be somewhat basic. The primary language is Java so a lot of the techniques are rooted in the kind of "move the dirt around" refactoring that you get with that language, and indeed covers what became the "refactoring" options in Java IDE's. Its a good overview of the ideas of refactoring, but often ends up creating more code and structure, since its often hard to change things in Java without adding more code.
Javascript has a lot more first-class options other than classes and interfaces, so there might be some more insight.
As far as good programming books, I quite liked Code Complete when I was a younger programmer, and found that Anti-Patterns was helpful in giving me a lot of vocabulary and patterns in recognizing what happens in job-settings, as well as refactoring overviews as a solution to real problems.
Javascript has a lot more first-class options other than classes and interfaces, so there might be some more insight.
As far as good programming books, I quite liked Code Complete when I was a younger programmer, and found that Anti-Patterns was helpful in giving me a lot of vocabulary and patterns in recognizing what happens in job-settings, as well as refactoring overviews as a solution to real problems.
Keep in mind that the original was written back in 2000. So most of the ideas in the book are pretty much mainstream these days. The second edition should be pretty interesting because of the move away from being class-centric.
When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful.
[1] https://www.martinfowler.com/books/r2p.html
When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful.
[1] https://www.martinfowler.com/books/r2p.html
The first edition suffers from being a victim of its own success. Much of it has become common wisdom and many of the refactoring techniques now have IDE support.
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
1. https://amzn.to/2I4rIWP 2. https://amzn.to/2GfxVTa
2.
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
1. https://amzn.to/2I4rIWP 2. https://amzn.to/2GfxVTa
2.
I really enjoyed the first edition, though I will admit I didn't read the true original, I read the Ruby version that was adapted for (and approved by) Martin himself. Given I do Ruby/Python programming, it was a better book for me than the original, but since I also do plenty of JavaScript programming, I imagine I will at least skim the 2nd edition as well.
I read it 15 years ago. No other book has influenced my programming as much as this one. The main value I got from it is that it teaches you what "clean" code looks like. Highly recommended.
You might also enjoy "Beautiful Code" then. While not everyone will agree that every example in that book is "beautiful", usually there's something in there for everyone. It's currently my favorite generalized programming book.
Thank you for the suggestion. I started that one but somehow never finished it.
Has anybody here read the first edition, and what was your impression of it?
It's a decent book, though obviously looking a bit dated now, particularly in the OO-centric presentation. I would confidently recommend it to someone like a junior developer at work or a keen self-taught programmer who had figured out the basic mechanics and was starting to explore ideas about building and maintaining bigger systems. I probably wouldn't recommend it to anyone further down the path, though, just because the techniques described tend to be quite simple and they're mostly things that people learn with experience anyway.
It's a decent book, though obviously looking a bit dated now, particularly in the OO-centric presentation. I would confidently recommend it to someone like a junior developer at work or a keen self-taught programmer who had figured out the basic mechanics and was starting to explore ideas about building and maintaining bigger systems. I probably wouldn't recommend it to anyone further down the path, though, just because the techniques described tend to be quite simple and they're mostly things that people learn with experience anyway.
To me refactoring doesn't need a whole book or set of terminology. So long as a person understands and values the principles the individual refactorings will come naturally with experience. In my view it comes down to three main points.
1. Refactoring does not change functionality. The observable behavior should be the same before and after.
2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct.
3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well.
I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough.
Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better.
I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).
1. Refactoring does not change functionality. The observable behavior should be the same before and after.
2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct.
3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well.
I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough.
Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better.
I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).
It is a must-read for anyone who programs systems bigger than a student class project.
It was a seminal book on software engineering for me.
Kind of like Effective C++, More effective C++, the old Win32 Charles Petzold book, GoF, etc.
To me, it was a classic, and much appreciated it as that was also when the whole TDD thing took off.
Kind of like Effective C++, More effective C++, the old Win32 Charles Petzold book, GoF, etc.
To me, it was a classic, and much appreciated it as that was also when the whole TDD thing took off.
Am looking forward to the book. Read the first one in the early mid 2000s and it changed my view of programming forever. Java in the modern climate isn't the best choice anymore to do this.
The move to a less class-centric approach is a much needed and welcomed shift. It helps to illustrate the spirit of the pattern or technique without getting weighed down with the restrictiveness and arguably dogmatic nature of java.
The move to a less class-centric approach is a much needed and welcomed shift. It helps to illustrate the spirit of the pattern or technique without getting weighed down with the restrictiveness and arguably dogmatic nature of java.
Am I the only one who thinks that using javascript is a terrible, horrible, no-go decision?
He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript.
I can't help but feel that he only chose this language because this is the language which will net him the most ROI.
And we'll take the collateral damage which is an influx of people who will wave his book and say "Let's use this language! Even Mr. Fowler uses it! This must mean that this is the best language there is!"
Imagine the damage this will do to us grunt programmers in the field. Now it will be even harder to push real languages through management now that a celebrity in our little scene is using javascript.
I bet that Mr. Fowler doesn't have to program in that crappy, quirky, horrible 9nth circle of hell language.
Sorry for the rant but this had to come out.
He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript.
I can't help but feel that he only chose this language because this is the language which will net him the most ROI.
And we'll take the collateral damage which is an influx of people who will wave his book and say "Let's use this language! Even Mr. Fowler uses it! This must mean that this is the best language there is!"
Imagine the damage this will do to us grunt programmers in the field. Now it will be even harder to push real languages through management now that a celebrity in our little scene is using javascript.
I bet that Mr. Fowler doesn't have to program in that crappy, quirky, horrible 9nth circle of hell language.
Sorry for the rant but this had to come out.
"the language which will net him the most ROI" is another way of saying "the language which the largest number of people will understand" which seems like a good thing.
This is intriguing, though personally I never connected much with Fowler's writing in the past (though I have gotten into his ideas).
Anyone know of any other good books about high-level design/architecture for javascript?
Actually, thinking about it, maybe what I'm really looking for is something for designing/architecting things in dynamic/weakly typed languages... (Been doing JS for a bit now, but I spent much longer in Java before).
Anyone know of any other good books about high-level design/architecture for javascript?
Actually, thinking about it, maybe what I'm really looking for is something for designing/architecting things in dynamic/weakly typed languages... (Been doing JS for a bit now, but I spent much longer in Java before).
Thinking Forth [1]. Yes, it's Forth and not Javascript. But it covers pretty much the same territory as Refactoring plus some pretty deep discussions on program design/architecture, for a book originally written in the mid 80s.
[1] http://thinking-forth.sourceforge.net/ Although you can buy a copy on Amazon.
[1] http://thinking-forth.sourceforge.net/ Although you can buy a copy on Amazon.
The book will be released in a series of ten thousand editions, each one modified slightly from the previous one but still correct and self-consistent.
You could say he... refactored it. <puts on glasses>
I'll get out now...
I'll get out now...
I'm stoked for the book. I'm surprised-but-not-really that it will use JavaScript as its main language to teach the concepts!
> When I wrote the first edition I was frustrated that I was having to write the book's code in a language that was significantly worse than the language I preferred (Smalltalk). Little did I know that I would take another step downwards twenty years later.
Oh, the irony!