Don’t be too eager when it comes to reusable code
While shared code is the mantra of every pro developer, sometimes we are too focused aiming to accomplish this myth we just forget the long term price.
Every new line of code you write comes at a price: you need to maintain it over the time until you decide to replace it with a new fresh bugged code.
In a desperate attempt to avoid it we start speculating over the future by making the code as generic as possible.
When possible code must require a low cognitive load to be understood. Over-engineering is a particular type of complexity where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. As reviewer you should be especially vigilant about over-engineering to limiting future speculation.
When about one year ago, with my team we started working on a complete rewrite of our company software we decided to follow three pillars: readability, modularity and reusability.
It’s almost easy to make reusable code when you perfectly known your domain but even in these cases you are not free from making mistakes.
And they happend, of course.
Few weeks ago we started working on two new big features in our project and we decided to share portions of the code between them.
In addition to some other conjunctions (good for another post) we didn’t know exactly every spec, moreover the product team changed idea during development.
The result is a failed attempt to create reusable code in the first place.
This post is a small lesson I learned from both these episodies from tech perspective.
While shared code is the mantra of every pro developer, sometimes we are too focused aiming to accomplish this myth we just forget the long term price.
This post continue on my blog — click here to continue reading.
