Getting Started with Refactoring

At this year's Global Day of Coderetreat (GDCR2025) our guest facilitator Ivett decided to ban AI tools. The result was a classic Coderetreat, like in the old days. It struck me in the retrospective that some participants said that they were unable to code by hand any more. They had a hard time working without their agents, and some ignored the constraint and kept using AI throughout the day. This is my empirical evidence that we lose the ability to code. (There is more evidence, recently by Anthropic how AI assistance (negatively) impacts the formation of coding skills.) Coding is dead anyway. Future "AI" developers might need more skills of the product owner, the architect, and the tech lead role. This is bad luck for junior developers, when they enter the market, as they are no tech leads (yet). Recognising that, a participant of the Coderetreat asked me how to learn (more) about refactoring. I believe that the basics are still important and share my answer here so it might benefit more.

Exercises and Books on Refactoring
Simon asked: "Do you know and can recommend any good exercises or books on refactoring." Certainly.

1. To get started, I recommend the book Refactoring by Martin Fowler. Martin published a 2nd Edition using JavaScript examples and the original edition is for Java, depending on what suits you better. Refactoring has two parts: Code smells and refactoring techniques to handle them. Both are described in Fowler's book and also on his website. Refactoring Guru is also good in explaining code smells and their matching refactorings. Go study these.
   
   
2. As for exercises - there are refactoring code katas. Emily Bache has many code katas available, including Gilded Rose, where the Readme often explains which specific skill the particular kata lets you practice. I maintain a small list of exercises here. Refactoring is a practical skill, which means you need to exercise it repeatedly, sometimes following the same steps. This is practice, and repetition is what makes it stick. Today, when using AI, you might skip the manual steps of refactorings at work, but you need to work the practical skill to master it.
   
   
3. The third pillar of fluent refactoring is using IDE shortcuts. (Or maybe refactoring workflows or skill files, who knows.) You should investigate the IDE you use most often, whether it is IntelliJ IDEA, Eclipse, Visual Studio Code, etc. Figure out which refactorings are supported - maybe install plugins - and practice refactoring using the keyboard. Refactoring becomes powerful when you know the shortcuts, because that is where speed comes from and you are no longer distracted by mechanics. I collected flashcards to learn the shortcuts and a quick search dialogue for finding shortcuts.

If you prefer videos, Dave Farley shared a list of free learning resources about building refactoring skill, confidence, and shared language, including Emily Bache's guide to core refactorings and practical tutorials which you can work through.

Using C# and NUnit
You mention using C# with NUnit. The Java refactorings in the first edition of Fowler's book transfer directly to C#. When working in C#, ReSharper or JetBrains Rider are useful, they provide more refactoring menus than vanilla Microsoft Visual Studio. NUnit is like Java's JUnit 4, any older book with Java examples will map well. There is also a special edition of the Refactoring book for Ruby. Most techniques are language agnostic.

Learning Tips
I strongly recommend starting with simple code smells, i.e. the group of Bloaters and then the Couplers. Practise basic refactorings such as Extract Method, Extract Local Variable, etc. Most IDEs support them and they build a solid foundation. Keep it small in the beginning. There is no point changing complicated code when you lack the basics. You could repeat the same exercise more times and try different approaches. You can always make exercise harder - and people take too large steps in the beginning. Instead make the exercises easier and take smaller steps.

Try to find a learning partner. Studying any material and discussing it with someone else is awesome for learning. Verbalising learned materials makes it stick. Discussing it with someone else helps you make new connections between the material. Practising refactoring in pair programming, like working during a Coderetreat, is powerful. I used to meet people in coffee shops or online and we would refactor code together.