Refactoring Is Not Just Clickbait - Kevlin Henney - NDC London 2023

For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.

Check out our new channel:
NDC Clips:
@ndcclips

Check out more of our featured speakers and talks at

[strayobject]

K. Henney is one of the very few speakers in the tech industry, whose talks one can be certain will be worth the time spent listening to.

[evyatarshafran]

Love this talk! Kevlin always makes these topics fun and interesting :)

[UserDirk]

Great talk that focusses on the true essence and origins of the Refactoring word.

[logiciananimal]

The "don't name negatively" is (more or less) in Aristotle in his discussions of classification. Hence Kevlin's advice has a very old pedigree. Also, functional requirements are often features, hence things, where as many of the "non-functional requirements" are properties (e.g., security, accessibility). Hence they are *metaphysically different*, and in particular, inseparable from the features they apply to.

[x--.]

This speaks to my heart. So often I've had other devs go on about this or that when my natural inclination is toward his descriptions here. Carefully understanding your problems and clarifying as you go.

[barneylaurance]

I always think of refactoring as relates to "factors of production" in industry, rather than mathematical factors. The factors are the pieces that go into a product, refactoring in a sense changes the pieces of a software product without changing the product as a whole.

[jeroenneve]

"don't name things negatively" should be "name things positively."

[kudorgyozo]

I would like to live in a make believe fantasy world where code is clean and understandable, and where you sleep 8 hours/day every time.

[nonchip]

it helps to remember what "refactoring" actually means: re-doing which factors go into the solution. not renaming, lots of people forget that.

[MrTetedacier]

I will follow your advice on playlist. I'm kind of locked on "know your ennemy"'s songs lately 😊

[CottidaeSEA]

Refactoring can be as simple as renaming the conditions of an if-statement. If I see a complex if-statement, I'll almost always give it a local variable at the very least. It makes life easier for the next person looking at the code.

[Soliber]

"Architecture is for developers to live in". I like that 😄

[philadams]

He's been giving the same old talk for years, but in a different way and repackaged up with different titles. You could say he's constantly refactoring it.

[not_ever]

He got me with the first IDE refactoring tweet 🙀

[StuCoates]

The regex at 1:03:38 doesn't consider leap seconds, which could be quite interesting... occasionally ;-)

[barneylaurance]

I think I don't quite like Fowler's definition of refactoring - I would delete the part about making it easier to understand and cheaper to modify, and say that a refactoring is simply any change made to the internal structure of software that does not change its observable behaviour. Then refactoring can be done for any reason, good or bad, and we don't have to know someone's motives to be able to tell whether what they are doing is refactoring or not.

[joebowbeer]

03:28 technical debt
05:50 technical neglect

[szirsp]

55:58 Because this is written in python I'm going to assume that it will run on a high performance CPU and not on a microcontroller. So this refactor might be appropriate, but still I would like to see some performance testing on it and not just "it does what we expect" unit tests. Because the original had a lot of branches there is a chance it performed poorly in today's highly pipelined architecture (though they have good branch prediction and speculative execution). Also because it is python performance probably doesn't matter and even if it wasn't it wouldn't.
But please don't refactor code like this on 8 bit or even 32 bit micro controllers that don't have hardware multiplier or divider !
The original code design (written in C) would run perfectly fine on an 8 bit AVR, or a cortex M0 ARM, while the rewritten one will be slower and bigger. (And it might also be harder to understand.)

And if you think this is premature optimization then you might be right but also don't be surprised how a modern text editor runs slower on current hardware than old ones did on much slower machines.

[anotherplatypus]

Wtf?... this guy's first few minutes is so funny so far...

[tomatoslav]

i need to write this comment down because i won't be able to focus on either this video or my work until i do ... the result of refactoring is often briefer, simpler code ... but it also often happens that new pathways are revealed for code execution that improve the performance of the code, and in some cases even open possibilities for new (QoL) features to be added