Code understanding, reverse engineering, best concepts and tools. Java

Question

One of most demanding tasks for any programmer, architect is understanding other\'s code.

For example, I am contractor, hired to rescue some project very quickly. F

Answer 1

By far the most important tools are your ears, your tongue and your larynx. Ask the people who are familiar with the code - they'll be able to help you understand its general architecture much better than any software tools.

Automatically reverse-engineered complete UML models are generally nearly useless because they cannot distinguish between important abstractions and implementation details - which is the whole point of such models.

Software tools are more useful to answer very specific questions when you are investigating details, such as "where is this method called from?" or "what classes implement this interface" - any good IDE will be able to do that. Debuggers can help too - placing breakpoints at keypoints of the code and looking at the call stack when they're hit is often very enlightening.

Answer 2

Just to elaborate on Michaels mentioning of good IDE's which can help you:

I use the following Eclipse facilities a lot:

• Shift-F2 when the cursor is placed in an identifier brings up the Javadoc for that identifier, if any. Good for navigating.
• Hovering the mouse over an identifier brings up a box with the Javadoc in it, if any. Good for reminding when writing e.g. a method call.
• The Declaration view shows the source where the keyword where the cursor is placed, is defined. This is updated when the cursor moved.
• F3 goes to the definition of the current identifier.
• Ctrl-T on an identifier shows all subclasses and implementations in a popup. Very useful when working on interfaces.
• F4 on an identifier brings up the implementation hierarchy of that identifier in a panel, which can be navigated. Very useful to learn how things are connected. This includes both classes and interfaces.

Answer 3

EclipseUML Omondo is the best Java reverse engineering tool. It reverse all the java code, all packages and even class interaction with interface if not in the same package. Just amazing. You can also reverse: - .class - hibernate annotations - JPA annotations

What I like with this tool is that my code is clean because all the model information is saved into an xmi format and not as tag in my code. You can also create small documentation inside each existing package using diagrams as a view of the model. Just marvelous and respecting the official uml 2.2 specification. The only problem is that it is really too expensive so the price is a stop for me !!

Answer 4

Doesn't extract high level architectures, but does make it much easier to climb around your Java code: our Java Source Code Browser. This reads source code (and supporting class files) and produces Javadoc style documentation plus source text bi-directionally hyperlinked to the Javadoc information. (I'm one of the principals behind it).

Answer 5

I use Enterprise Architect for whole UML (including reverse engineering with Java) and it works perfectly.

Answer 6

The book Object-Oriented Reengineering Patterns deals with this in detail. Unfortunately there is no silver bullet attached :-)

However, it lists a lot of useful techniques for taking over legacy code. In brief

• interview at least some of the original developers (if they are still around) about
  • development history: phases, releases
  • current state of affairs
  • team social structure, politics, dynamics: when and why did people join and leave
  • bugs: typical, easiest, hardest
  • code quality: cleanest / ugliest parts
  • configuration data: form, content and usage
  • unit / integration / manual / ... test cases and data
  • SCM branch structure and usage
  • documentation: what is documented where, is it up to date
  • contact persons for external interfaces
• Watch developers / users during demo to find
  • main features
  • typical use cases
  • usage anecdotes
  • good / bad, missing / superfluous functionality
• "read all the code in one hour"
  • get high level view of class hierarchies, interfaces
  • take multiple sessions if needed
  • identify large structures (these often contain important functionality)
  • look for design patterns
  • check comments (they can reveal a lot, but may be also misleading)
• skim documentation (if there is any)
  • just record the availability of specific types of docs e.g. specification, UML diagram, Wiki, Javadoc etc.
  • is it useful and why (not)
  • is it up to date