Deciphering foreign code

Question

What is the best strategy to go about understanding some one else's code for a medium sized project, if the code is not well documented and does not adhere to many coding standards?

Answer 1

My approach:

1. Play with the app (use it)
2. Check the code organization (layers/entities etc.)
3. Generate references diagram (i.e. using NDepend for .NET)
4. Look for some code patterns in code (this will give you some ideas what the author(s) tried to implement)
5. Don't dig into details too deep at start.
6. Focus on understanding the dataflow (i.e. how are lists populated, how is data saved, for example: UI->BusinessLayer->DataAccessLayer->SLQ Stored Procedure)

Answer 2

I'm assuming there are no unit tests. The best way I've found is to take the time to follow the workflow; see how it interacts from the user's point of view and try to see how the code is called - then you can rename things to be more meaningful.

Answer 3

The first thing I would do is read about the project and use it, from a user's perspective. Read the Software Requirements Specification (SRS), user stories, or whatever form of documentation exists for the requirements. Then, try to complete some of the core tasks and understand how the system is used. I feel that if you don't understand what the system is supposed to do from a user's perspective, it's incredibly difficult to design and implement solutions to problems these users are facing.

One technique would be to read design documents and follow through the code. Dynamic diagrams (sequence and communication UML models, for example) are especially useful, if you have them. These enable you to see a graphical representation of the relationship between code modules (packages, classes, and methods). Of course, static diagrams (class, package, object, deployment UML models) are also useful in understanding how pieces of a system fit together. If these diagrams don't exist, spending a little time reverse engineering the system might be a good learning exercise.

Given your situation, though, it sounds like documentation might not be available. The next option would be to use a debugger. Turn on the debugger and walk through the system as its running to see how it fits together. You can run through several common use cases and step through methods. It might be a good idea to comment files as well. Perhaps make notes of things that you question or need to learn more about.

Answer 4

I would start with finding out what the code is supposed to do. Is it a web application that processes banking transactions? A desktop application that HR uses to manage resumes and applicants?

Next step would be to try running it. Explore one feature well. Then put breakpoints in the corresponding code and step through it with the debugger - if you are able to. This will let you see the "living" code - how it works when it is actually running. If the documentation has been poorly maintained, the debugger might be better than any documentation as it's possible that the documents have not been udpated as the code changed.

It is also be good to ask someone else in the organization who has more experience with the code, assuming that such an individual is available.

As others have mentioned generating diagrams can help if you have tools that are good at it. But keep them small at first. A diagram that contains hundreds of classes and possibly thousands of relations between them is pretty useless (at least at the begining).