How to understand existing projects

Question

Hi. I am a trainee developer and have been writing .NET applications for about a year now. Most of the work I have done has involved building new applications (mainly web apps) from scratch and I have been given more or less full control over the software design.

This has been a great experience however, as a trainee developer my confidence about whether the approaches I have taken are the best is minimal. Ideally I would love to collaborate with more experienced developers (I find this the best was I learn) however in the company I work for developers tend to work in isolation (a great shame for me).

Recently I decided that a good way to learn more about how experienced developers approach their design might be to explore some open source projects. I found myself a little overwhelmed by the projects I looked at. With my level of experience it was hard to understand the body of code I faced.

My question is slight fuzzy one. How do developers approach the task of understanding a new medium to large scale project. I found myself pouring over lots of code and struggling to see the wood for the trees. At any one time I felt that I could understand a small portion of the system but not see how its all fits together. Do others get this same feeling? If so what approaches do you take to understanding the project? Do you have any other advice about how to learn design best practices?

Any advice will be very much appreciated. Thank you.

Answer 1

Communicate

I would usually ask a developer to give me an overview of the project or any of the project modules that I am interested in. I haven't found so far anything that is better than communicating with the developers involved to be introduced to an existing codebase. They can not only give you an overview of the project and code but also recommend any available documentation (e.g. class diagrams) that may be worth looking at.

Answer 2

You should always be looking for a better way. That, at it's core, is where you drive yourself to get better. Always asking "there has to be a better way" is a good thing -- but don't let it paralyze you. Set a time to try something, if you're not getting anywhere, ditch it, go another route.

What does change is people you trust, people you can bounce ideas off of and communities you can look to. I do this all the time with a short list of people that have worked with me before, are better than me in areas I know I suck at, and don't mind telling me "no, bad, you should do (some other idea)". That step you've already taken with posting something here :-)

Regarding projects - everytime I approach a project that already exists, isn't mine, the people who wrote it are not around, the code is old, the documentation is sparse and so on, I tend to focus on ONE THING and one thing alone. Don't try to understand the entire system, that's unrealistic and don't worry too much about if your changes are the perfect fix/solution/whatever -- that'll come out over time and become obvious as you improve and understand things more. Know what you don't know and make no bones about it and learn one channel at a time. Even knowing a ton of tricks and cool things don't mean a whole lot when you have to go back to 2003 with datasets.

You mentioned people are very isloated ... that's too bad because developing anything requires a lot of people talking to each other. I would suggest asking if you can pair program with one of them that knows a lot about the system. If that person makes excuses or says "they can't" find someone that will.

Answer 3

This is a very interesting question. I also would like to know how other developers do this. Up until now I use these possibilities in no particular order:

• Read the source code, it has the advantage that it is always up to date. It is also the most difficult task, but it is possible.
• Read the unit tests if they are available, they often show the intended use for a class, library or framework.
• Refactor a part of the source code. While you are improving the quality of the source code you increase your understanding of the code, or should I say you can only improve the source code if you know exactly what it does.
• Debug the application, step through the program while using a debugger.
• Use a tool like NDepends, JDepends, Lattix, Visual Studio etc. to reverse engineer the architecture or design of the application and use that as a starting point.
• Read the documentation. Any documentation that enables you to understand the application will do (user documentation, design documentation or architecture documentation).
• Communication with the original developers as Bruno said would also be a good option.