I went down the wrong path recently. This topic relates to internal APIs and to discuss this I must ensure I define this.
When performing a refactor, the idea is that you can make any changes you want as long as the external contract remains the same. The internal components which talk to each other are all fair game when performing a refactor.
I have been in a position where these internal APIs were also like external APIs in that multiple people use these APIs to deliver their functionality, but we all own the maintenance and updates.
This meant they were treated more like external APIs. This is a pain to do and it feels like so much more work.
Well I found myself positioned were I thought the API was self contained enough I could just throw it out and reimplement. I think that is still the case but what a mistake.
See the biggest benefit to supporting the old API while doing a refactor is that your code still compiles and your tests still pass.
Dynamic languages can avoid this as code you're not running does not need to work to test the code you're working on. I could not handle needing to run all the tests to find issues the compiler tells me about right away.
When I continue to maintain the old API I could technically merge in progress into mainline. Sure that would create some confusion, but it still makes it a possibility.
Top comments (0)