In this post, I wanted to explore my thoughts on software architecture and how it is (or isn't) applied in commercial (non-open source) software. Applying good architecture principles is always top of my mind when I'm making a changes to source code. Would this apply to you? What is your thoughts on this topic? Share below!
I came across this Linus Torvalds quote in a folder on my NAS and it's left me thinking... A lot:
My interpretation of this quote is that the data structures are the composition of the software whereas code is the algorithms - the logic to get the output desired from given input.
Algorithm is Important
In my (trying to be) humble opinion, in modern software, the architecture is far more important then the algorithm used to implement the feature. Hear me out.
Yes, the algorithm used to achieve a goal is important; I don't mean to sound like I'm completely dismissing that aspect. Of course, an algorithm can be good or bad; that is efficient or inefficient. Consider the following "bad" algorithm (which is commonly shared as a joke):
By and large, professional programmers don't write such ridiculous code. At least, I've never seen it. By my observation, professional developers usually produce reasonable, efficient-enough code and while it often can be improved, it's rarely worth the time.
I know I fall into this category and I think most professional programmers/engineers would.
Since professional programmers do write reasonable code, the slack in unperfect algorithms is easily made up by the speed and efficiency of modern computer hardware.
We use MVC, that is our architecture!
I might expect someone to respond with that. And it's true, the MVC architecture pattern is widely utilized and found in a lot of commercial web software. But, MVC alone isn't enough even when followed perfectly.
There are so many aspects of a program, architecture should be considered for each component. How are you structuring your models, for example? Are the models becoming monolithic? Your controllers? This is what I've often observed.
This makes maintenance and change very difficult. Not because the change itself is difficult. It's easy to insert code in to an existing function. The problem becomes bug and issue regression. Boiled down, you are changing the intended input / output of that module and breaking it's singular purpose.
Doing this one or twice may be tolerable, but when you have half a dozen developers doing this - all with their own agenda and features to implement, the bugs can be confounding.
Architecture is Important but...
There is a balance, of course. One shouldn't spend 90% of their time refracting existing code into academic design patterns - or even common design patterns. That isn't what I'm driving at.
I'm suggesting that when you are planning a change that you more-strongly consider what you are modifying. How can you package your changes to honor (but not necessarily strictly be) the SOLID principle.
I'm confident in saying that a little bit of thought towards this on each change, feature enhancement or bug fix would go a long, long way in improving the maintainability in a code base.
After all, the purpose of most design patterns or architectural patterns is not to make the program faster or improve efficiency but to make changes specifically easier to manage. Either through unit testing, component isolation or some other facet.