Design for code maintainability
I have come to acknowledge that any code can very easily morph to that Italian spaghetti you love so much. No one wants to write bad code. But as code ownership goes from one developer to another, requirements change and the continuous pressure to get features rolled out mounts, developers tend to tie things together to make the feature “work”. And as time passes by, the code can become easily unmaintainable unless it is continuously groomed to be maintainable.
Any project being actively developed, by 5 or more developers for a year, can easily become unmaintainable.
What does it mean for code to be unmaintainable? When something you thought should take hours ends up taking weeks. That is when you can safely say you have unmaintainable code.
Code maintainability is easier to recognize when it is absent
Code maintainability should not be an afterthought. It needs to be a continuous process. A true measure of good code or a software is one which stands the taste of time. Code which has been written to be well understood and has simple logic, will win you the race.
Always think of the poor soul who will come in years later and try to use or refactor your code to fit in new functionality.
When code is easy to read and simple to understand, new developers will use it properly simply because they can comprehend it better. Otherwise, chances are high that they would simply retrofit something to get the job done, rather than spending time trying to understand the beautifully designed code which, once understood could be used to even solve world hunger.
Here are some of my personal opinions which I have formed over the years on how to achieve code maintainability:
- Avoid retrofitting functionality — This is the number one culprit which makes code unmaintainable over a period of time. Once you retrofit, you will need another feature, which you will end up retrofitting on top of the retrofit. In short, it is a rabbit hole, you don’t want to walk into. Try to spot them early, and avoid them completely.
- Don’t re-architect your code for features you don’t know — Design only for things you know. Be open to refactoring the design as you go to suit your needs. To do safe changes, build up a good automation suite, which can give you the confidence that your expectations are held as you keep changing the code.
- Follow SOLID principles — Always try to be true to the Single responsibility, Open-Closed and Interface segregation principles. If you try to adhere to these principles, it will automagically structure your code to be maintainable.
- Use design patterns with a purpose — If you have places where known design patterns make sense to use, use them and more importantly name your classes meaningfully.
- Simplicity — I cannot emphasize enough on how important it is to write simple code and keep the overall design simple. Follow the KISS (keep it simple, stupid) principle to the heart. As soon as you spot that some parts of your code are starting to grow, it is time to step back and reflect on the overall design and responsibility of that part of the code. Refactor to keep things simple in the light of new requirements.
- Less is more — Don’t shy away from removing code. Code which is not needed and just lying around means more code to maintain. Get into the habit of removing dead code.
- Do error handling properly — Error handling is an important and fundamental piece which dictates how logic flows throw your component layers. Put some real thought on how you want to do it for the project at hand, and follow it consistently throughout.
Writing maintainable code is not rocket science. The key takeaways are keep your code simple, avoid retrofitting or taking shortcuts and be conscience about code maintainability.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.
If you like this post you might find this interesting as well:
