If you try to take on all this refactoring at the same time as the change you were originally planning, that’s a lot of stuff to fit in your head. Maybe you’re a refactoring wizard, in which case go for it, but I wouldn’t trust myself to handle that kind of cognitive load without making any mistakes. It’s much safer to split the work into stages: either make the change, then refactor, or vice versa. Don’t try to do both at the same time. Splitting refactoring work and other changes into separate commits in your version control system also makes it easier for you and other developers both to review the changes and to make sense of what you were doing when you revisit the code later.
The Mikado Method
Every software developer with a few years of experience has endured this situation: You want to make a small change that should take you a few minutes. However, when you start you see one problem after the other you need to fix first, then you need to refactor here a bit and something there, and before you know it, a day has gone by and you are no step closer to implement your change.
That extra work is not complicated, but you try to solve a problem on top of an endless list of other problems. Your tests started to fail right after the second refactoring and after hours of work you would be happy if your code just would compile. The longer this takes, the more frustrating it gets.
What I like so much on the Mikado Method is that you need only a slight little change in your routine to prevent those problems. It is so easy that you will not believe that this makes any difference. But trust me, it works. The high-level view on the Mikado Method looks like this:
Set a goal
Experiment
Visualize
Undo
0 comments:
Post a Comment