Understanding a big company project in Java [close

问题:

what is the best way to understand a big company project in java?

回答1:

You'll never know every line of every piece of code at a company. What you CAN do is understand the classes, what they do, and how they relate to each other.

Start by getting the most basic understanding of the way the code flows from a class perspective focusing on the large classes that do that majority of the work. Once you understand what's happening there start focusing on smaller classes. Keep this up until you have a pretty good understanding of a handful of classes.

Additionally you can break it down in to common programming tasks that your company has. Once you have a list of these research what's involved in implementing each of them.

The final thing is just experience. You can study the code as long as you want, but there's no substitute for playing with the actual code. Writing programs, testing things out, and looking at how existing code runs are the best way to learn a new system.

回答2:

There's a nice podcast/interview with Dave Thomas ("The Pragmatic Programmer" Dave) about this topic, here.

He calls it "software archaeology".

For many different reasons organizations frequently lose control of their code bases. Knowledge gets forgotten, people leave. One could very easily mistake the code base for an archaeological concern were it not for the fact that mission critical applications built upon it keep chugging along until something needs to be modified or enhanced and then suddenly you have a vat of source code that no one understands but that has become the most important thing in the world overnight.

There are very few short cuts for coming to terms with big vats of code. Generally, one has to balance the quest for "understanding it" with the pressure to make pointed pragmatic changes to "complete the mission".

回答3:

Start writing unit tests - you do something useful (which will probably earn you more time to understand the code) and you get an in-depth look into the functionality. Also, start asking questions when they come up during that process, you will be able to ask very specific questions and you might impress your colleagues :)

回答4:

Few places I often start from is the build/package/deploy scripts and configuration files - depending on the size of the application we are talking about, they can tell you a lot about the internal structure, external dependencies and highlight things to dig in further.

Next you can use code coverage tool and record the coverage for a simple scenario, which points roughly which areas are performing it. A variation of this is running under tracing profiler. Heap dumps are also useful for getting an idea of the basic data structures.

Finally, look application logs during various scenarios, though these are usually too much information and you need to know what are you looking for.

All these should give you a good idea of the overall application. After that, you need to fire up a debugger and start poking in the code. Ask your colleagues for their favourite breakpoint locations - usually everybody has some.

In case you are doing Java or C#, make sure you know your IDE and how to use find-usages. There are further more advanced tools for static analysis and comprehension like Structure101 (my favourite), SonarJ or LattixDSM.

Some UML reverse-engineering tools can generate class diagrams, but usually they create too much noise and doing the pruning manually assumes you can discern the important from the unimportant (which usually is not the case with new codebase). If you get one of these, I recommend starting with essential class and using the "Add dependencies" functionality to incrementally explore the application.

回答5:

Take a simple first task, and don't rush anywhere. Look around, use the time to learn and understand the environment. Examine the call stack, use a debugger. And when you have a solution, ask your peers for a code review, and learn from them. Then take another task, and another one, and another...

You'll get there soon :)

回答6:

Documentation my friend, look for manager patterns seek the jsp play with the code dont be afraid to make small changes and see what happens, understand the logic and the building blocks, stay way from companies with poor documentation.