Krista's Coding Corner


System architecture –blueprint of the program

System architecture is to a program something like blueprints are to a house. It tells how things are related to each other and how the process of working goes in the program. Basically it says how the program should be coded and how it is supposed to work in reality.

I didn’t intend to write about system architectures as they are something quite complicated, fragile (ugly) and I don’t have too much experience with them :) However, I have come across and heard about so many system architectures that are fundamentally flawed, so here it comes:

The bigger the program ( == the more files and lines of code), the more there seems to be dependencies if it hasn’t got good architecture. Let me show you two images and hopefully you can immediately say which one is more clear, understandable and easily comprehensive in the sense that what is happening in the program:

Unfortunately programs are virtual and making more and more functions into them is quite easy. If we were building railroads, we would think really carefully, where and what kind of tracks we put. But not with programs. That’s probably why there are programs that look like the image A and not B (and just imagine what happens when there is more parts than just those four!).

If you do any programs that are even a bit complicated, it is good to do some sort of an architecture drawing. Not that you need it but you will learn how to do it, and other people can more easily understand your program and what part of it does what.

In practice: if there is good architecture with good documentation, any programmer can take over your project / help you with it but if the program is just spaghetti, it is hard to get help, as an outsider (or maybe even you) can’t see what effects what and where the errors actually might come from.

Depending on your programs size, boxes you draw can represent individual functions, files or even services. Most important thing is to draw correctly how they have connections to each other and what box needs what box to actually work. Connections can be marked with arrows and in most of the cases there shouldn’t be arrows pointing back and forth. If needed, different kind if arrows can mean different ways of communication (for example: using different protocols if used services are in different computers :) ). And of course if you have an architecture made to a service-level, you also should have more detailed architecture about the services if you are making them.

Just remember that if we make a house, we need the blueprints! And if blueprints are bad, it just causes problems after problems.

PS. Stick with your plan == architecture! Otherwise there is no use of it and then everything easily turns into spaghetti :/

blog comments powered by Disqus