REFACTORING 2018

Could you explain what refactoring is about?

Refactoring is evolving code to make it easier to understand and easier to change over time. It’s making the code communicate clearly what it’s doing. This leads to simplification, of course.

It’s been 20 years since the original book – what’s changed in that time?

20 years ago refactoring was an unknown term (outside of the Smalltalk world). The book put refactoring on people’s radar. This was important because it underpins adoption of Agile methods in general, Extreme Programming in particular. It really is a cornerstone technique.

Will this book help people in a legacy Javascript environment?

I hope it will help people in any legacy environment. While the examples are in Javascript, it's not a Javascript book. Just as the original book was not a Java book. Whatever programming language you're in, hopefully these techniques are broad enough to be useful.

What are the main changes from the original , Java exampled book, to the new, Javascript one?

The biggest change was making many of the refactorings in the book less class-centric. In Java, of course, everything has to be a class, everything has to be an object. So as a result, all the refactorings are expressed in that mindset, in the context of classes.

Of course, that's not necessary to refactoring at all. It's just an accident of when it was written. Now it's more about using classes as one of your structuring options, not necessarily the primary one. That goes beyond renaming extract methods into extract function. Obviously that is necessary, but it goes beyond that.

Is that part of moving from object-orientation towards a more functional style?

That, of course, depends what you mean by ‘more functional’. We are talking about Javascript, which is not a functional programming language. There's no guarantees of the immutability, so we can't really operate in what most functional people would consider a functional way.

And, in fact, that's why you still need classes, because classes are designed to structure mutable data. And so it is more functional to some extent, in that there's more use of class functions than there was in Java.

Ironically, it's harder to do immutability in Javascript than it is in Java, you have to do a lot more through convention. And you've got some really awkward gaps in the language to work with values, for instance. So you could argue that Javascript is less functional than Java, in many ways.

There will always be some differences across language environments, so I have tried to keep the book’s lessons broad, and we’ll see where it goes from there.

Is there a place for something driving towards elegance and readability in functional programming, or is that something that comes with the language?

That’s an arguable, and interesting point. I’m very interested in Brian Marick’s exploration of functional programming. He questions whether there’s actually much of a drive within the functional languages community towards readability and understandability full stop. It’s an interesting thread and I’m keen to see the thinking that emerges there.

I haven’t gone deep into the nuances of the community mindsets. Different communities all have different qualities and I’m an outsider to them all, because I dabble in many.

Do you think it's important to be a generalist — and would you consider yourself to be one?

In terms of coding languages, yes. I think to be a truly good programmer you should be a generalist. The languages are all different tools, you should work with them and learn from them all. 80% of good programming knowledge will carry across any language - and that’s true of refactoring.