Hello Reader 👋

I hope you are doing well today!

Next week, I will animate a hands-on workshop at DDD Europe. For 2 hours, I will teach 30 people how to craft their own automated refactorings.

And since my head is deep down into "refactorings" these days, I thought it would be interesting to share a few handy moves with you today!

Just before we dive in: if you are a late bird who wants to join me and attend DDD Europe next week, use this special link to get a 10% discount on the tickets. It's better than nothing 😉

Alright, let me show you 3 cool moves…

Decompose Conditional

I don't know you, but I often stumble upon some complex conditional logic. It makes the code lengthy and, often, tricky to understand. Sometimes, I know what happens but not necessarily why.

A helpful habit I took is to break down this code into smaller, easily understandable bits—these can either be variables, or functions. Clear names will make the condition easier to read, and highlight the intention.

Step-by-step, it looks like so:

Return Modified Value

Code becomes a puzzle when we can't track how data is modified. It gets worse when multiple fragments are messing with the same data, making it hard to follow the flow.

This is THE refactoring to remove mutations across the codebase and untangle the mess. I find it very useful to learn how to perform this move safely, especially when there is no test around.

How it works: instead of mutating deep in the code, we return values to bubble up the updates. It reduces the scope of mutations and clarifies what's happening.

Introduce Value Object

Have you ever noticed variables that are always passed around together? Yeah, me too, all the time!
​
Regrouping them together opens the door to clearer code. And it turns out Value Objects are great for that!

In my experience, it's a good way to start introducing missing concepts, Domain Objects that are hiding in the code. It makes existing code easier to grasp, and new code simpler to express.

Note: in JavaScript, many developers prefer to avoid using classes. The language allows for different styles and, personally, I think classes are fine when used properly.

It's also totally fine to use regular functions instead. Instead of hiding the data structures, we compose functions that operate on immutable data structures. The idea is the same 👐

​

I hope you have found these step-by-step refactoring illustrations helpful. I'm working on more.

Let me know which refactorings you would like me to work on. Or maybe: what code smells do you frequently see in legacy code? I may have some refactoring moves to suggest to you 🤠

Until next time, take care!