# Refactoring: Avoiding tunnel vision with the Mikado method

> The Mikado Method involves mapping out the dependencies of the refactoring, then refactoring starting from the leaves of the resulting tree.

- Author: Mathieu Eveillard
- Published: 2023-03-15
- Updated: 2025-06-27
- Tags: Refactoring
- Canonical: https://www.mathieueveillard.com/blog/methode-mikado/
- Translation (fr): https://www.mathieueveillard.com/fr/blog/methode-mikado.md

![Refactoring: Avoiding tunnel vision with the Mikado method](https://www.mathieueveillard.com/blog/2023-03-15-methode-mikado/methode-mikado.webp)

“Method! Method!” my advanced math teacher used to yell. It hurt my ears, but she was right. She was right to talk about method, because **if there’s one area that demands method, it’s refactoring**.

## Real-life scenario

The weather’s nice, it’s cool this morning, you slept well, and you’re feeling ready to refactor: a noble intention.

The problem is that very quickly, one change leads to a second, then a third, and the list just keeps getting longer. You open parentheses without ever closing them. After an hour, the app won’t launch anymore; after two, compilation is nothing more than a vague memory; and at 12:30, it’s time for lunch.

A coffee ☕️ and off you go again: well, it would be a shame to waste a morning’s work, wouldn’t it? So you keep going, you keep pulling on the thread, and you open new parentheses. **You’re deep in commitment bias**.

Just a reminder: the app no longer compiles, so your changes are becoming increasingly unstable. You’re working without a safety net and introducing bugs left and right.

Your codebase now has a faintly post-apocalyptic feel to it ☠️ A week has gone by, and you can feel your manager’s breath on the back of your neck as he walks past, pursing his lips to keep from saying anything.

It’s time to bring a little structure to this. Let’s take a look: “The problem is that very quickly, one change leads to a second, then a third, and the list just keeps getting longer.”

## The Problem of Dependencies Between Refactorings

The answer is right in front of us: **each change that needs to be implemented depends on another change, all the way to a final one that, in turn, depends on nothing**. This is how a dependency tree takes shape.

The Mikado method therefore proceeds in two steps:

- The first step, the exploration phase or knowledge-acquisition phase [↘️], consists of building this tree. Starting with the change you want to make, you identify the next change it depends on, and the next, and the next, until you reach the leaves of the tree. Interestingly, at each step, you start over from the initial state (`reset --hard`). This is useful for working from a clean slate and evaluating the precise consequences of the change under consideration. However, if the change is small, it can be implemented directly.

- Once this tree is established, the refactoring phase can begin [↖️]. It proceeds by starting from the leaves and working its way back up to the root of the tree, that is, the change that started it all. The analogy with the game of Mikado makes sense: you can only reach the last stick after removing all the others first.

## The Challenges of Refactoring

This method, like the [Strangler Fig](https://www.mathieueveillard.com/blog/strangler-fig-pattern) pattern, helps counteract tunnel vision and avoid the mega-refactoring that’s supposed to take a year but will ultimately be abandoned after two.

**The other major issue with refactoring is, of course, the risk of regressions**, which can be mitigated using the [Golden Master](https://www.mathieueveillard.com/blog/golden-master) method. All of these topics are covered in detail and in a practical way in the course _The Art of Refactoring_.

So… happy coding! 💻