Understanding a system comes in pieces but each piece can take longer or shorter time depending on the circumstances.
What does it mean, then, to understand a system?
Well, if you don’t understand it and introduce a change, you risk going wrong. The code you wrote may seem to work, but …
– You put the change in the wrong place so everyone else is confused.
– Your unit tests ran fine but some other part of the code wasn’t under test and stopped working promptly.
– Your change introduced a dependency to another component and we now have a circular dependency.
– The system can’t be deployed because there was a distributed interface which you thought were local.
– You didn’t follow the policies of error handling, logging or security. So now there is a security breach which is not caught by error handling and the log is nowhere.
So that’s the "why" of understanding. The "how" has some answers you probably know already.
- RTFC: Read The Fine Code. Yeah, that’s what we do. All the time. Don’t tell me to do something I do all the time. Thank You.
- Ask a Guru. There are gurus? No, guru means teacher which means the opposite of withholding information. That’s what some do, to be in need. Baaad. But you have to deal with it more often that you wish.
- Write unit tests until you get it. No harm in that if you do it as you go.
All these have the drawback of looking at the details without seeing the big picture. It reminds me of when I was 13 and learned the city by areas around the subway stations. After a while the areas got big enough to connect to each other and I could get the overall picture without looking at the map.
What is the big picture then? Well, it is the architecture of the system. There is no mystery about it, no magic patterns put down by a long gone super genius, no outdated ideas, just plain descriptions of how the system is designed.
Like a house is understood from blueprints of the outside, the disposition of rooms, the plumbing, etc, a system is understood from different views. There is a standard that will tell you that there are views but leave it to the author to decide which views.
The one I have seen most of is Kruchten’s 4+1, published in IEEE Software. You should be familiar with it but I guess you are not. I have a course on system architecture and I am still surprised how few of the students that have ever seen a document describing a system’s architecture, despite several years in the business.
The crash course is to study the Wikipedia article linked above. Start with the logical view and the physical (deployment) view, those are easiest to grasp.
But there is more to it. Remember that I said something about going wrong with logging, error handling and security? Those are principles of the design and impacts the system almost everywhere.
So to understand a system, I think you need the details and the views and principles of the big picture.
Oh, was the Wikipedia article too long? Here is a cheat sheet:
- logical view: how components of the system relates to each other logically.
- physical view: the servers and firewalls and stuff like that.
- process view: how processes and threads are related.
- development view: where the compiled code is package, e.g. a war.
- scenario view: important functions of the system.