Understanding a large Java program

I am working on a java project and I have to extend (add more functionality) it. But I don't know how should I learn the existing one before incorporating them. Is there any specific path I should follow? Can I run it in a way so that I can see, statement by statement, the execution of the program?开发者_如何学Python

I am a kind of stuck in understanding it, thanks.

---

Here is another approach that is hacky, but I've found useful in the past when unable to attach a debugger. If there is a piece of code that you are looking at, but are having a hard time figuring out who is calling it you can throw a new runtime exception, catch it and print the stack trace.

try {
  throw new RuntimeException("who is calling me");
} catch (RuntimeException e) {
  e.printStackTrace();
}

---

You can always fire it up in a debugger/your IDE of choice and step through it all you want, though it's probably best to find someone who is more familiar with the source to provide you an overview, or to look for documentation on where to start.

---

Pick one piece of functionality for which you understand the requirements. Find the entry point for that feature and follow the code for that one feature. It should give you a good understanding of how the architecture works.

---

Integrating with code that is already written can be very difficult. In my experience, some of the best clues I've gotten about already-written code come from the method signatures (the mapping of the function's input to its output). The method's signature can give you a lot of hints about a program, namely where and especially how that particular method fits in the context of the larger program. Usually, a method signature coupled with a descriptive method name can give you enough information to be dangerous, especially in a typed language like Java.

Although I wouldn't suggest running the code line by line and looking at changes (because this usually amounts to tons of work) but for really ugly but important code sometimes it is necessary (I've definitley done it before using DDD for C programs). In this case, a quick google search reveals http://www.debugtools.com/ , a graphical java debugger, which may do the trick; there also seems to be version of DDD that works with Java.

---

This is a recurrent question on Stack Overflow. There is already very good answers all around:

• https://stackoverflow.com/questions/3147059/taking-over-a-project
• Cleaning up a large, legacy Java project
• https://stackoverflow.com/questions/690158/how-do-you-learn-other-peoples-code

Also, this book might help: Working Effectively with Legacy Code

"Patience and fortitude conquer all things." - Ralph Waldo Emerson

---

I would recommend you to start with the debug as well so you can go through the program step by step.

---

• Documentation:

  If you have documentation, it’ll be helpful. But it can be a pitfall, as much documentation is out date, they can be misleading you.

• Bugfix:

  You could start with bugfix or new feature implantation. Start work with small scope, it’ll be easy work. During the bugfix, you could understand the code more and more.

---

1. Baseline the code, I generally would use git
2. Do a build of the application
3. Run it.
4. If baseline fails build or process is too complicated, create a branch and fix it
5. Create a branch and modify a string or something that would show some visible change if you modify the code.
6. If Javadocs are not created via ant or build files, create a new branch to do this.
7. If there is no JUnit test cases (or if there are but they don't work), create a branch and fix it.
8. Create a new branch to do the merge.

The following is if you're using Eclipse or similar product

1. If you're the only developer, create a new branch and set up project settings for code formatting and cleanup. Then execute the code formatting and cleanup. This would allow you to have a more stable baseline for future work. If not, try to coordinate with others.
2. Install FindBugs, Checkclipse, PMD to do some simple checks on the code base. Looking at WTFs sometimes will give you a better idea on how things are working (or not)
3. Install Eclemma and see how much of the code is actually tested.