Context

I am sure that you are faced with a situation where you found a couple of classes that solve the same problem but in a different way. Also, when you implement or maintain similar modules you could find that entire code or specific classes look analogous. Here is how you could use it as leverage for your productivity.

Identify

Identifying such cases is key. Of course, without that, we can’t do the next steps for the improvements. Sometimes we have to refactor given code because is implemented in way different way, but after “normalization” we get the same code. I faced such cases many times, especially when working on legacy code.

Improve

We could do the improvement described in the previous sentence - refactor the code, so it could look very similar in every module. But this is only part of the improvement we could do.

Implement a pattern

Once we isolate a common class (a subset of methods in other words), then we could: check whether it’s doing a single thing and doing it right. Then we could divide the given class into smaller independent parts.

When we will be in this place we could introduce interfaces for all important classes. The complement step is to make those interfaces and concrete classes generic - a lot of languages are using “templates” or some corresponding method.

Replace old solution with generic one step by step

If you identified such classes in a couple of modules you should avoid replacing them at once. Does it step by step, so you could test everything properly and react to some problems if any would occur? This way you will discover them faster.

Summary

Thanks to the steps described above you will be able to implement something only once and use it anywhere else you need. Polymorphism is a game-changer here, it’s an increasing number of places that we could use our code later on.

There are a couple of benefits that we get from described approach: - we have less code to maintain in the long term - we need to spend less time doing it - we need to remember less about our codebase - we have only one file when we want to improve feature X - what’s more important we have one file to take a look at when searching for a bug culprit (we will be able to easily map file/class to a feature) - we could unit test our code way easier and faster - we decrease the complexity of the solution - we decrease the time needed to introduce a new person to our project - when having interfaces in place (that hides all other details under the hood), we could prepare very tiny documentation that will show connections between modules and interfaces :) - your team would be spending less time on code review and debugging bugs

You need to remember about couple more things: - it’s a process, and you should not try to do the last step in the first place, you need to take time to decouple code correctly (do it only when you know the system is your pocket) - remember to inform your teammates about changes - they should reuse your code to not waste time and don’t spend time on re-inventing the wheel

I know everybody loves spending time coding things. But by saving time you will be having it on doing another great thing with your app like preparing a design, discovering customer needs, helping your teammates, or just implementing another feature/fix way faster than planned.

Probably there are way more benefits from using the approach I described. You can share them with me of course!