You don’t choose what your forebears have written, though.
You don’t choose what your forebears have written, though.
And the more you put in procrastination-encouraging half-solutions, the worse your code base gets.
There is no right way. Only grey ones that help relieve pain for the team.
> Refactors and rearchitecture are.
Yeah... if you have the cash and the people. Usually, mature codebases are driven by limited investment with proven business value, because the sweet VC money is no longer there (or never was, in some industries).
If you don't, reachitecturing is vanishingly rare, and your refactor budget is limited and you spend it carefully. If a piece of code hasn't moved recently but still comes up frequently when onboarding newcomers, documenting the code may be more profitable and less risky than changing it. It also helps preparing a case for a potential refactor.