When building software, a quality that is often overlooked by many developers, is designing for extensibility, allowing for software to be easily built upon and grown, after the initial conception. The benefits, to this, are enormous, as it not only reduces potential future workload, but in doing so it ensures a cleaner codebase as one would be designing it to be worked with in the future.
Why is it important?
Building software to be built on in the future is a highly desirable trait to have as a software developer, as it shows an attention to detail that many developers, especially juniors, fail to possess. It also allows for much faster bug fixing, as when building a system in such a way, it naturally begins to follow a very logical flow which begins to enable much faster debugging and error catching. It also paths the way for relatively future-proofed software and allows for developers of any background to easily pick up from where the previous team left off.
Why does it matter so much?
To best convey why building software to be extended is so important, I find it best to speak about a project I worked on where the code was built in the exact opposite way; let’s call the project, Azure. When I joined said project, it had been worked on by approximately 5 dev teams, with each one piling more code on top of an already broken codebase, as opposed to refactoring and fixing up the pre-existing codebase. The end result of this when the team I am in came to work on the project, as over a week of just sorting out compilation issues and recursive dependencies. The very definition of legacy code hell. This same project will be a constant struggle for over two months to properly clean up, whilst maintaining a live product.
It also allows for better collaboration in larger teams / codebases, as instead of having to reinvent the wheel for the umpteenth time, a co-worker could build off a pre-existing system. The benefit to this is huge, as not only will it result in cleaner, more robust code, with each extension following the same pattern and overall design as its’ parent, but it will also allow for less time and money being spent on a project, as developers will not have to spend their time creating 50 different ways of doing the same thing.
How can software be made for extensibility?
Abstraction, abstraction, abstraction. The process of abstraction allows for a scalable and rigid system to be put in place, whilst also allowing for parts to be hot-swapped out and replaced when needed. It also enables code to be built around parts of the system without knowing many of the aspects that could eventually be made into extended files. This offers a large degree of flexibility, whilst also designing the system to scale well into the future, as the fundamental logic is already provided, yet encourages developers to build on top of it.
Can extensibility be done incorrectly?
Yes. Extensibility has its place and should only be done in specific circumstances, where it makes sense to do so. Whilst it is a great way of ensuring the software will last for an extended period of time, using it in every scenario will only complicate the entire codebase, without much benefit. A guideline to go by when determining whether to make a part of the codebase extensible is, is it used in more than once place? If so, write it to be extended. Your future self will thank you.
Extensibility is a concept that any serious developer should be aware of as it promotes the longevity of a codebase and enables less work to be spent recreating the wheel countless times over. It boosts collaboration in larger codebases, as fellow developers are able to hook into pre-existing systems and provide their own functionality, on top of systems that have already seen use; therefore, providing a solid base of stability. It enables debugging to be far easier, but should only be used when the abstraction of the core functionality makes sense.