How to understand existing projects

Question

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.

Here are some good steps to consider before diving into the source code of any project you never looked into.

1st step - try to understand the purpose of the project (first overview then at low level) if possible take the help of tester.

2nd step - before going to code, try to design the project on your understanding at a very high level.(don't spend much time on this, just at a very high level).

3rd step - execute the project and see the flow it will give you more clarity on the understanding of the functional design.

4th step - see the structure of the project, it will give a very basic idea of the architecture like three tier, two tier etc.

5th step - again execute the program in debug mode and try to understand the technical flow at module and class level. means which module contains the business logic and where the data access logic is written also try to understand the input and output for these modules.

6th step - Note your understanding for future reference.

7th step - once again execute the application in debug mode, this time understand the purpose of the class and the methods it contains. execute different functionality of application in debug mode and each time follow the control where ever it's going, see the classes and all the methods of this class and try to relate it with the functionality you are executing eg - if you have selected a page 'account' and filled the entry and submitted.(you know that it's going to open a new account for you - just follow the control in debug mode and see what are the classes involved and try to understand their methods then at the end of this cycle you will understand many things about account opening technically). apply the same process for different functionalities.

Cheers!

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.

Question i asked myself when i started my journey. First and foremost it requires lots of patience and time depending on the size of the project. Here is what i do today to understand an existing project and the projects i work on mostly are database centric and this list is not necessarily for open source projects but also for work place projects

1. Create an ER Diagram of the database ( if it is a relational database )
2. Create an ER Relational sheet with all relations of the tables laid out ( here is a sql query http://blog.sqlauthority.com/2006/11/01/sql-server-query-to-display-foreign-key-relationships-and-name-of-the-constraint-for-each-table-in-database/)
3. Use the above sheet to create Views to group the tables logically and see the results. This helps to understand the schema and data behind application
4. Diagram to lay out the tiers and the components in the project
5. Sequence diagram and data flow diagrams to understand the flow
6. For the above you need to debug the application using tool like visual studio
7. Class diagram and reference maps of methods to undersand the chain in code ( can use tools like Resharper )
8. Functional specs ( or write your own story of the project ) and use case diagrams ( to understand business requirements )
9. Refactor a small portion to understand the code better
10. Talk to developers or community or business

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.