
Announcing the Second Edition of “Refactoring” - apolretom
https://martinfowler.com/articles/201803-refactoring-2nd-ed.html
======
digorithm
Wow, this is huge!

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!

~~~
solipsism
_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.

~~~
jeremiep
He probably went where most developers are. Just like choosing Java over
Smalltalk for the first edition.

I feel its better to reach more developers, than aim for the best technologies
that very few are actually even aware of.

~~~
digorithm
Exactly my thoughts!

------
neves
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?

~~~
Karunamon
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?

~~~
dgreensp
TypeScript is fast becoming the go-to language for JavaScript with types.

~~~
edem
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.

------
quietbritishjim
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).

~~~
hyperpape
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.

~~~
quietbritishjim
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.

~~~
hyperpape
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.

------
thaumaturgy
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?

~~~
jacobkg
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.

~~~
saryant
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.

~~~
jmsaucier
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.

~~~
bcbrown
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.

~~~
funkymike
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.

------
thinkersilver
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.

------
edem
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.

~~~
simonlc
I'm curious as to what you believe are the "quirks of javascript" and if you
think there are any more reasons as to why it's a "crappy, quirky, horrible
9nth circle of hell language"?

Thanks.

~~~
edem
Just google it. There is not enough space here to list them all.

------
westoncb
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).

~~~
spc476
_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/](http://thinking-
forth.sourceforge.net/) Although you can buy a copy on Amazon.

------
CobrastanJorji
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.

------
IgorRinkovec
You could say he... refactored it. <puts on glasses>

I'll get out now...

