I have a method of coding/refactoring that I now automatically do, but I realise I don't know what it's called.

If I am making a change, and realise there needs to be a change to some existing code, I always consider if I can do that change first, without any change of behaviour. If I can, I do so, making sure tests pass, commit, and deploy if possible. Only then I actually make the change for the task at hand.

Sometimes, this earlier change might reveal to actually need another change, which can also be done first, and so on. (Although this being nested several levels deep has been quite rare, probably because the initial size of the task I set out to do I try to keep small anyway)

What is this method called?

  • 1
    This reminds me of the "vertical slice" concept in agile. You're essentially refactoring a vertical slice in preparation for a behaviour change. – MetaFight Feb 18 '17 at 15:06
  • 2
    You isolate the preparation step in order to do one change at a time. If you test and find an issue after doing multiple changes it will be harder to find where you went wrong. So I would call the approach careful or conservative or "playing it safe". If that doesn't sound computer sciency enough to you, I could call it "multi-staged" or... chicken. – Martin Maat Feb 18 '17 at 19:17
  • @MartinMaat The "chicken" method... I like it! – Michal Charemza Feb 18 '17 at 21:56

I'm not sure there is an official name for this method.

But clearly, by analogy with graphs, you are an adept of what I would call depth-first change propagation : when you perform a change, you always deepen the scope of your changes, by opening additional changes at another level of detail.

The traditional approach of "one change after another" would be more like a breadth first approach: every change (level) is first implemented before considering the propagation of changes to the next level.


I'd call it just refactoring but with micro commits, or micro commit oriented workflow. (I just came up with that.) Highlights from the linked article that lists the benefits of this method:

  • micro commits show the incremental process through which you reached your final solution
  • more disciplined development practices
  • better code reviews
  • bisect and cherry-pick become more useful
  • I think it's a similar to microcommits, but microcommits doesn't quite explain the entire method. It's not just committing often, it's also splitting the change in a way where the current fix/feature is in the last commit, and all the commits before don't change behaviour and are releasable (if possible). – Michal Charemza Feb 19 '17 at 22:17

That reminds me of Joshua Kerievski's Limited Red and Refactoring to Patterns approach.

The Narrowed Change pattern could match what you describe, depending on what you mean by "there needs to be a change to some existing code".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.