What's the best approach in auditing a big java/j2ee web application

Question

I have to audit a large web Java/J2ee application that has evolved over several years. It's been written by some other company, not the one I'm working for. In it's current state it has become hard to evolve and maintain, new functionalities are hard to add and often lead to bugs that sometime show up in production. There seem to be some copy/pasted code which resulted in code duplication. The current app is some kind of online shopping with some cms-like content here and there. It's mostly Struts and some Spring in newer parts of the code, maybe some ejbs thrown in for good measure. There are some unit tests available, but not a lot of them. These are things I've been told, I haven't seen yet the actual code.

My company will make a proposition to rewrite parts of this app in order to reduce complexity, improve quality and modularity, and make it possible to add easier new functionalities without regressions. Before making any commitement, they would like to have some kind of appreciation of the quality of the existing code and to asses how much of it can be reused, in order to have more than a guess in what there will have to be done - full rewrite or partial rewrite.

The catch is that I'll have to do this in a very short period ( a couple of days ) so I'm trying to work out a plan for what can be done in such a short time. What I'm thiking is :

• check out "basic" things - exceptions treatment, logging
• check out the level of layering ( views, controllers, dao layer )
• measure the actual coverage of the unit tests
• maybe run some Checkstyle, Findbugs and PMD over the projects
• ...

So the actual question is what other things should I take into account/check/measure/etc ?

I'm not sure what kind of numbers I could get out of this and if it would really mean something, I have the feeling that what the management is asking is kind of the wrong approach, so the second question would be : does anyone has a better idea ?

I'll appreciate any idea, suggestion, comment on this.

Edit: I'll be adding two dead code detectors to the mix : UCD and DCD

Answer 1

I like your list quite a lot. I think you have an excellent plan of attack to start.

I'd look with an eye to standardizing on either Spring or EJB 3.0 but not both.

I haven't read it myself, but I wonder if Michael Feathers' book "Working Effectively With Legacy Code" has any good ideas?

UPDATE:

Maybe you can help things by putting them on a automated build and continuous integration - Cruise Control, Hudson, or Team City. If you have to do any refactoring it'll help.

Answer 2

You're focusing on maintainability and extensibility which is spot on.

I would add looking at how long it is going to take to reboot the project. Do they use source control? Do they have separate environments for integration and user acceptance testing? Is there a build server?

When you have to spend two months before the first improvement appears someone needs to manage the client's expectations upfront.

Answer 3

I had two web applications with similar settings as you. I stopped using FindBugs and Checkstyle as they showed more than 10.000 problematic points. The applications used JDBC level data access, JSP for presentation and a custom framework for request dispatching. Luckily for me, these low level settings allowed me to do the extensions and fixes on medium difficulty. During the 3 year project, only about 20% of the original code remained as it were. Sooner or later everything else needed to be either changed, replaced or removed (and finally I was able to use FindBugs and Checkstyle).

We too faced the dilemma of complete rewrite. However, there were several factors against it:

• Not sure customer will pay for a complete rewrite.
• The lack of functional and technical documentation makes it risky to do the complete rewrite.
• Manhours to fully understand the complete application was too high. Customer wanted the requested changes sooner.
• The users where customed to the presentation and page behavior. It seemed hard to convince users to use a new interface for old functions.
• If we do a complete rewrite, we need to provide complete documentation. For update, we needed to document only our part.
• It is hard to convince the management (own and the customer's) of a rewrite if the program works (more or less)
• The company had its own PMD rules and the code didn't pass. It was simpler to argue that it is enough the new parts pass the test.

It boils down what you want to do actually.

Do you want to rewrite, despite the complexity?

• Put emphasis on the code bugs. Large pie charts with lots of red is convincing.
• Explain the program properties and how they don't fit into the corporate vision.
• Show enhancement options beyond the current requirements and describe how the current version is not up to the challenge.
• Do interviews with the real users. They might point out important problems with the current version.
• Be cheap but a good estimator. You might delay some costs till the maintenance phase.

You don't want to rewrite?

• Put emphasis on the cost, especially the manhours required from the customer to re-test everything.
• Point out the potential trouble of breaking functionality.
• Ask for a full-time document writer.

If you want to taste the code, try to add the Hello World! function/screen to the application. That tells how hard and how fast you can implement new things.

Answer 4

In fact they won't pay for a full rewrite, because :

• It's recession, the cost of you rewriting it from scratch will be high

• They might be trying to sell the company ASAP

• The management doesn't understand anything about software development

I would first go with some simple facts :

• Use a tool to display the SLOC of the project
• Run as you planned FindBugs and eventually PMD, just to estimate the defects
• Do a quick profiling session
• Check the different layers
• See if resources are generally closed (Streams, Hibernate or JDBC connections, etc.)
• See if technologies are used where they don't apply (EJBs, Web Services, etc.)
• See how they handle exceptions and logging
• See if there's too much or not enough abstraction
• See if you could add some base classes to reduce code duplication

Try to draw a quick diagram of the architecture of the application, if they don't give you a document about it.

Gather some statistics and some facts, write a report and send them to the company. They'll want to minimize the costs and they'll ask you to avoid fixing code which is not broken. You start with the statistics, then to the facts and a proposition with time/approximate percentage of code affected/pricing.

Usually legacy Struts applications are a pita to maintain, been there done that. If it wasn't part of your job, I would say let it go. If you come across "standalone" pages which don't involve many templates and are subject to many changes, propose to rewrite them with some other technology.