If you’re refactoring something – do it iteratively.
Recently I was refactoring some code, it was time to pay off some debt. We have modular monolith and it appeared that one module was clearly a part of another, they just ping-ponged themselves all the time.
I was convinced that it was trivial. Communication from and to the module is done entirely via the module’s API. So it’s enough to move all files from the obsolete module to the other one and done. Right?
Technical debt is a tool – use it, but use it wisely.
Technical debt is cool. Am I crazy? No, I think it’s a great feature (yes, feature) of agile development. Let me explain.
Technical debt is there. We can safely assume that in the very moment you finished a feature and pushed it to production – it’s debt. Best code is no code. But let’s talk about intentionally creating it.
Let’s say you like to write good, readable and tested code. You take care of DDD, use best practices, create caches when necessary. But then business has an idea for a feature, and they aren’t sure if it’s gonna work but they wants it fast. If you’d try to make this feature as you like, as your engineering soul tells you, you’d say “ok, give me a week or two”. There are disadvantages to that approach.
Review your own code after some time, or another task.
Some time ago I had an idea. What if I could do a code review for my own code? Of course It would be nonsense to do it just after code was written. But what about day or two later?
This idea appears probably in the time, when I was the only backend developer in my team (holidays or something…). In such situation creating too much code and making too much tasks could be worse, than doing nothing. Checking this code would take all of my teammates’ time, I’ll have to make some fixes to at least some of them. And even, when the rest of team will be present, they will do CRs of my code and what could I do then? Writing more code equals more CRs. Infinite loop 😉 In such situations slack time would be better option imho.
So, I thought about some ways to be more efficient in such conditions. And self code reviews appears.