Do It Either Way, We'll Refactor It Later
Do It Either Way, We'll Refactor It Later
Join the DZone community and get the full member experience.
Join For FreeDiscover a centralized approach to monitor your virtual infrastructure, on-premise IT environment, and cloud infrastructure – all on a single platform.
It often happens that a new piece of functionality is discussed within a team and different developers have a different preference over how it should be implemented. “But what if in the future…” is a typical argument, as well as “that way it’s going to be more extensible”.
Well, usually it doesn’t matter. One should rather focus on how to write it well, readable, documented and tested, rather than to try to predict future use-cases. You can’t in most cases anyway, so spending time and effort in discussions which is the perfect way to implement something is fruitless. I’m not advocating a ‘quick and dirty’ approach, but don’t try to predict the future.
Sometimes there is more than one approach to an implementation and you just can’t decide which one is better. Again, it doesn’t matter. Just build whichever you think would take less time, but don’t waste too much time in arguments.
Why? Because of refactoring (if you are using a statically-typed language, that is). Whenever a new use-case arises, or you spot a problem with the initial design, you can simply change it. It’s quite a regular scenario – something turns out to be imperfect – improve it.
Of course, in order to feel free in doing refactoring, one should have a lot of tests. So having tests is more important that implementing it right the first time.
There is one exception, however – public APIs. You cannot change those, at least not easily. If you have a public API, make sure you design it in the best way, especially consider if any given method should be exposed or not. You cannot remove it afterwards. In other words, whenever a 3rd party depends on your decisions, make sure you get it right the first time. It’s still not completely possible, but it’s worth the long discussions.
I generally refrain from long discussions about exact implementations and accept the opinions of others. Not because mine is wrong, but because it doesn’t matter. It’s better to save the overhead of guessing what will be needed in one year and just implement it. That, of course, has to be balanced with the overhead of refactoring – it’s not exactly free.
Learn how to auto-discover your containers and monitor their performance, capture Docker host and container metrics to allocate host resources, and provision containers.
Like This Article? Read More From DZone
Published at DZone with permission of Bozhidar Bozhanov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}