Refactoring (or as i often annoyingly call it, "Furniture arranging") is a skill that once practiced enough, becomes second-nature, and in a lot of cases, very easy.
It often gets conflated with design, but they are separate activities.
Refactoring is just improving existing code and not changing behaviour, and it's usually very localised changes; tests shouldn't have to change. A lot of very helpful refactorings are simple to learn, easy to do (many are almost entirely automated by your IDE) but over time become hugely impactful to the quality of our system.
Design often requires bigger changes and bigger conversations, and usually has a level of subjectivity to it. It is easier to talk about design when the underlying code is well-factored, which is why it's so important we keep refactoring. If we don't, we'll find it hard to do good design.
I'd like for us to get a bit more disciplined at this, get in the habit of running through a mental checklist every TDD cycle. The more you force yourself to practice, the easier it gets.
- Inline variables. If you create a variable, only for it to be passed on to another method/function, you should consider inlining it (
command+option+n) - DRY up values with extract variables. Using the same value multiple times in a function? Consider extracting a variable and capture it in a meaningful variable name (
command+option+v). - DRY up stuff in general. If it feels hard to do, you're probably making things more complex, consider stopping. DRY with care, practicing this frequently will improve your judgement.
- "Magic" values. Capture them as constants or variables, give them a name.
- Excessively long public methods? Encapsulate the steps in private methods/functions with extract method (
command+option+m). We'd prefer our public methods and functions to describe what it does, rather than how it does it. - Confusing names? It's so common for method names or variables to go out of line vs what they mean. Shift+f6 and make things clearer.
You should run your unit tests every time you do one of these small changes. We invest time in making our code unit testable, and the feedback loop of a few milliseconds is one of the big benefits, use it!
This is not an extensive list, just a start. If you want to become a pro, read Martin Fowler's Refactoring book (2nd ed).
We should always be striving to leave code in an exemplary state, code that is easy to read, is easier to change and redesign. Messy code is hard to work with, so let's try and keep our lives easy.
@quii Good stuff! I'm suprised so often when I've heard folks come back against a variable rename and label as I'll create a bug for tech debt. Big fan of incremental improvement in the course of work rather than pushing little things off.