The Perils of Refactoring

The Perils of Refactoring Typos

/via http://www.commitstrip.com/en/2018/11/26/if-its-not-broken/

Funny cartoon, but the whole "Don’t refactor craetionDtae”, thing is a bit far-fetched, right You’d probably fix that typo without thinking twice about it, right?

Wellllll, maybe not. After all, this might actually be something that is exposed to users (it’s in the API. Yay), so you need to refactor this and the documentation, but that’s OK, you can do that, right?

Wellllll, maybe not. Because, now that you look, you notice that you’ve got two sets of typos, craetionDtae and craetionDate, which means that refactoring means that you need to update both of these in the code and the docs, so now it’s 4 things that need to be changed, but it’s ok, you’ve got that, you can do it, right?

Wellllll, maybe not. Because, now that you really look, you realize that craetionDate also exists as craetionDates (because, you had to pluralize the array, didn’t you?) and craetionDateForUser (because you forgot that craetionDate already existed), and now stuff has grown exponentially, and you’re not really sure that the refactoring won’t f**k with the other names, and it’s all just too much now.

And that’s the real reason you didn’t go ahead with refactoring it, right?

Wellllll, maybe not. In reality, it’s probably just that one craetionDtae typo, and nothing else. However, you don’t know! And, because of that, you’re probably not going to actually do anything, and craetionDate will live on forever in your code.(And, a couple of years from now, when you’re long gone, nobody else will refactor it because they don’t know either, and assume that you probably had a reason for this…)

(This article also appears on my blog)

The Perils of Refactoring was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.