Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

After reading some projects, I find that it is not the architecture of the software that is really hard to know. It is not hard to figure out the architecture immediately if the project is clearly designed and implemented, if it's hard and never seen before, some day later I can find out some pattern similar to the one I read in the same domain.

The difficulty is that the concepts and mechanism defined by the author are really hard to guess, and these concepts may spread in the whole project which makes it hard to grasp. The situation is normal and universal and you can ask questions to your colleague when in a company. However, it gets worse if nobody around you knows these details. How do you handle these details which block your reading?

share|improve this question

closed as not a real question by gnat, user281377, Mark Trapp, jmo21, Walter Mar 27 '12 at 12:56

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers 2

up vote 4 down vote accepted

Welcome to the world of legacy projects :-)

In reality, there are an awful lot of projects with spaghetti code, no up-to-date documentation and / or noone around to reliably answer technical questions.

However, software that is still in use always has users, whom you can ask about how they use the program, common use cases, quirky or strange behaviours they experienced etc. etc. This helps you understand the problem domain, and also - indirectly - a fair bit about the implementation as well.

This helps you get a feeling of what the important, central components of the program are. Thus you can focus your efforts and use your limited time better. Another means to identify these is to look at the source control commit history (if the project has one). The components modified most often are either the most actively developed or the most buggy parts of the code (often both).

The gist in all these is to try to separate the important details from the unimportant details, so that you can focus on the former.

Then you may start writing tests - both on the high and low level (i.e. system and unit tests) - simply as a means to record the existing behaviour of the program, and to understand it better. It may not be correct behaviour, but this is where you can start anyway.

Armed with tests, you may also refactor to learn - if you see a piece of difficult code, refactor it little by little to make it cleaner and easier to understand. If the code is covered well with tests, you may keep the results of your refactoring. Otherwise, you better throw it away as a prototype, and keep only the knowledge you gained.

This earlier answer of mine on SO may also help.

share|improve this answer

Same kind of problem I was facing lately. It was a pretty big firmware project. Now in case of the firmware, user is far away from the code that developer has written. So, he is not of much use in understanding the code! If the code is modular enough, well documented/commented/linted, one can grasp it very well. But if it is not so, you need to push yourself hard. As you said, if you have understood the architecture of the software, you should draw a starting point for yourself. That will do good as a reference point in the beginning. Start going further, when you feel stuck at some difficult part of the code which is appearing again at many times keep it aside. Try linking whatever you are reading with the architecture as a whole you have understood. This approach might help you later or sooner to fill up the blanks that non-understood code might have created! This is something like a big jigsaw puzzle; You know what picture it is...but the pieces are too small and so too many! Hope this helps a bit!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.