Reverse Engineering poorly documented Java from source [closed]

Closed. This question is seeking recommendations for books, tools, software libraries, and more. It does not meet Stack Overflow guidelines guidelines. It is not currently accepting answers.

---

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 1 year ago.

Improve this question

I'm a systems engineer, recent college grad, and I've just been given a project that is exceptionally daunting.

We have a le开发者_如何学运维gacy system, we legally own the entire code and all rights to it. The problem is that the code is poorly documented, what little documentation is incomplete, sometimes wrong and the original devs are unavailable.

It uses a custom Perl build script requires a thousand modules from CPAN to work and I do not know Perl. Reverse engineering into UML has failed except with Doxygen and that is limited to just inheritance diagrams and call graphs.

I've obtained a massive chalkboard and I'm slowly trawling through the code, modeling packages and then the nested packages within.

My question is whether or not I'm approaching this reverse engineering from the right direction. I'm working close from the bottom trying to figure out what calls what while developing UML and writing a Design Document. I did a package diagram but it's hard to figure out what's going on at that high a level.

An academic paper I pulled up suggests I also make a new Requirements Document which would slow me down even more and I don't know if it's a good idea as the other developers are always busy trying to keep the legacy system up.

Are there any books out there that can help me and am I approaching this from the right angle? Should I hire a contract worker that knows Perl and JMX to assist me?

---

The book "Working Effectively with Legacy Code" by Michael Feathers will probably help you more than anything we can tell you here.

However, the most important thing you need to clarify for yourself (and from your question it sounds like it's not completely clear) is this: what is your goal? What do you want to achieve with this codebase?

If the answer is (as it sounds) "being able to effectively maintain the existing project", then trying to directly build a complete high-level model of the system may not be the most effective path. It's probably just too much at once to keep in mind.

In this case, I would try to understand only the use cases of the system that you currently need to modify; follow method calls through the code (pssibly using a debugger on the running system) to see what parts are involved. Do this for a few different use cases and you'll start to see patterns, then document those and gradually fit them together into a high-level image of the system.

---

This tool might assist you.

Or if the legacy system is written poorly it could just make a huge unreadable mess, but I hope it helps.

---

If it is a java code then a deep reverse engineering would be very helpful. See a documentation at: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html