4 ms·
Assuming any piece of code won't or shouldn't be changed feels wrong. If you're a library developer you have to put processes in place to account for possible c
by kcb 4y ago
Assuming any piece of code won't or shouldn't be changed feels wrong. If you're a library developer you have to put processes in place to account for possible change. If not those public interfaces are just as refactorable as any other code imo. Nothing would be worse than not being able to implement a solution in the best manner because someone decided on an interface a year ago and enshrined it in unit tests.
- randomdata 4y agoMuch, much worse is users having to deal with things randomly breaking after an update because someone decided they could make it better. That's not to say you can't seek improvement. The public interface can be expanded without impacting existing uses. If, for example, an existing function doesn't reflect your current view of the world add a new one rather than try to jerry-rig the old one. If the new solutions are radically different such that you are essentially rewriting your code from scratch, a clean break is probably the better route to go. If you are confident that existing users are no longer touching your legacy code, remove it rather than refactor it.