Kevlin Henney

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.

It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming also represents a way of thinking. Having only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.

Perhaps even more problematic than being stuck with a narrow view of paradigms, is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation have a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.

This session explores the strengths and weaknesses of different programming styles, patterns and paradigms across different programming languages, past and present.