You may want to inform yourself about human rights in China.

On "Pure" Refactoring

date: 2024-08-01

I’m confident there’s nothing new here, but I’ve never saw this approach being linked to (functional) purity, as in, side-effects free.

Let’s say that you have a piece of code to be refactored. What we’ll do is implement, aside of the current implementation, the new implementation. Saying it otherwise, the old implementation won’t be removed until the refactoring is complete, and guaranteed to be correct.

A pleasant addition to this is to have extra layer of indirection(s), allowing to isolate both implementations, and eventually select either one via a configuration flag.

For example, say you have a function dostuff(). You’ll want to add a function dostuff_new() for the new implementation, and say, (there are many ways of doing this), rename the current dostuff() to dostuff_old() and have dostuff() select between dostuff_new() or dostuff_old().

Sleepy little guy

Sleepy little guy by M. Bivert through instagram.com

What’s great about this option is that:

Hence the title of this article: this is a side-effects “free” approach to refactoring: instead of altering a piece of code, we add a an “altered” version next to the old one.

Note: A similar approach can be taken to implement “versioning” to an API: if there’s a need for an interface update, just add a new route. There’s then little need to bake versioning within the API itself.


Comments

By email, at mathieu.bivert chez:

email