4 ms·
I agree, but not having an interface is a great way to make sure you probably are never able to swap out the implementation (even if someone came along and want
by hardwaresofton 4y ago
I agree, but not having an interface is a great way to make sure you probably are never able to swap out the implementation (even if someone came along and wanted to do all the work).
Drastic fixes and Rewrites almost always consist of three things:
1. Writing tests to ensure functionality
2. Writing an interface or shimming the existing functionality to redirect control flow
3. Implementing and testing the rewritten functionality/improvements
Obviously you can't do it everywhere, but life is much better when (2) was done up front.
- kjeetgill 4y agoIt depends on a dozen details, but one of the strengths of a language like Java for me atleast is that it's pretty easy it is to do those things fairly bug-free. One of the biggest dimensions that completely change this conversation is: module boundaries. If you're in a position to touch all of your user's code, it's night and day vs if you're pushing migrations on other teams or God forbid customers. But if you have all of your code? In Java atleast, it's cake.
- wfrew 4y agoReally you should have those tests upfront. After that noone should be scared of changing any part of the codebase. Let alone 'never' changing stuff. Releasing rewrites / redesigns behind a feature flag, with a couple of strategic if statements is usually good enough. Noone cares that you had to change code outside of your interface for a release or two.