If It Breaks, Then We’re Good
Let me tell you a story.
Once upon a time, there was a brave warrior named Devel Oper. This brave warrior had seen enough corruption in the kingdom he was serving, and decided to burn it to ashes (with the collaboration of his fellowship Cod’er and Tec Hlead) and start over. It wouldn’t be pretty, it would take them time, but this new kingdom would be more respectful, safe and… modular?
A handful of us (sadly, not everyone can take company time for such an endeavour) have found ourselves improving the codebase. And probably not a single one of these refactors was blissful and without any trouble. Classes, that break? Sure. Are arguments no longer available? Uh-huh. Are dependencies no longer satisfiable? Tell me more.
Is it bad? Well, yes. Is it good? Also yes.
If it broke, then better sooner than later
It is okay to break a thing in a controlled way (that is, during a refactor), rather than finding it out via your customers. When something breaks, there’s a reason underneath, but you haven’t seen it yet. Have two classes vaguely named the same way, with roughly the same fields. Require it as an argument for one class, pass it as an untyped object to another class, let this other class cast again, but mistype the dependency. In most cases, it could work flawlessly… until you ask for the field that’s not there.
When you refactored that (maybe moving it into a different module, maybe renaming a few classes, simplifying them who knows), something could break out of the blue, and it would be catastrophic, except that you found it in your own computer, and not on an error log worth millions.
If it broke, it was too coupled
Why do some things break? Because some code requires too much of another. It is a classic that you notice during a refactor, that a business logic class depends on a UI data transfer object. We can imagine it the other way at some point, but why should the domain logic furiously need something from the UI, without even processing it in any single way?
The same happens when two code blocks with very different goals (for instance, authentication code and data visualization code) communicate way too much with each other. Do they need to? According to the pre-refactor code, yes. Move the authentication code to its own place, and now you can’t see those cute graphs.
If it broke, it is not SOLID enough
Let’s say you refactored the code to a seamless, perfect module. Except that… you have had to compromise a few situations of code repetition among different modules, to make it work. And also, right after you commit the module, you notice that it’s actually 2 different modules! Or maybe, all of a sudden you have to extend some classes and change their behavior on this module because otherwise, it wouldn’t work.
Well, if you have all that stuff, count the days before it breaks on its own. This seems very cheap, but SOLID code tends to break less (and be easier to extend).
If it didn’t break, did you cover all the cases?
Imagine it the other way around. You do a refactor worth 2 weeks of your time. And nothing broke? What’s wrong with that then? If nothing breaks, it should be a reason to be happy.
Check your tests again, because either your code was already pristine, or somebody’s about to work late next week (and it’s not me).
If it didn’t break, are you really using that?
Believe it or not, we, developers, like to keep code around. Yes, even in the age of version control, we believe that having a plethora of old code around is worth the bytes it weights and the reading time it needs. If you moved something and your code didn’t change, either I really want to see that perfection or that code is simply not used. It’s not bad to discover that, it’s maybe disappointing that you spent the last 4 hours refactoring that class and it’s worth nothing, and you’ll probably want to keep it in case somebody did that on purpose (they never do).
