How to audit a Java EE project?

问题:

I've to audit the code-architecture quality and maintainability (in the end to be sure we have what we paid for) a Java EE web project based on JSF/CDI/EJB3.0/JPA (just to name some of the technologies involved).

This may not be the right place to ask but how do you deal with this kind of task? Basically, I would proceed from coarse-grained to fine-grained, i.e. from the whole architecture to the java code. Is it better to deal with each layer completely? Should I spend more time on the low-level layers?

Do you assess the whole thing (build, deployment, test)?

回答1:

At the lower physical/implementation level, what I like to do is adopt maven as a build tool, and then configure the extensive maven reporting, to produce a website full of various code metrics.

• For starters there is the maven checkstyle plugin which can report on code conformance to a specified standard, consistency in coding standards has many obvious benefits, most projects would simply adopt one of the pre-configured standards e.g. sun or apache.
• The findbugs plugin lists potential programming errors
• There are a choice of code coverage reports, I've used cobertura. These show line for line in an application which parts are covered by unit tests. Maven supports unit tests in the build life-cycle, running them as part of the build. This has saved me a few times.
• The PMD plugin identifies duplicated code, and highlights areas that may need refactoring.

Once this is setup and becomes part of the normal build cycle, it basically takes care of itself, and you won't have to worry about doing large bi-annual audits/catch-up.

Many of the reports have threshold limits that can be configured to fail the build if breached, i.e. more than n% checkstyle errors, cause a build failure.

Maven also promotes a modular approach to building applications, this results in smaller more understandable and re-usable modules, as well as separation of concerns, i.e. separate modules for presentation and persistence layers. The main benefit that maven provides is managing the inter-dependencies between the modules.

This doesn't help you very much at the higher-level architecture layers though, so a complementary approach will be required to cover that dimension.

See some sample reports at this link
http://maven.apache.org/plugins/maven-dependency-plugin/project-reports.html

回答2:

To help in the code level audit and probably in project health too one software that can help is SONAR... it's very simple to setup just some maven commands, comes with a lot of proven code standards like code quality, reusability, bad practices measurements and so on...

it Runs on your project SVN or CVS and generate a website with graphics represent past and current status of the metrics it's creating, so you can navigate the project data and keep track of the improvements or faults.

It also uses all those maven and maven plugins listed in the other answer like cobertura, find bugs etc...

http://www.sonarsource.org/

Just download and point to your Repo.

回答3:

In addition to the lower-level code metrics and static analysis already mentioned, I'd add a tool like Structure101 to help analyze higher-level structure and dependencies. It can also help in refactoring the same.

Identifying clusters of dependencies can help determine if the app was written with separation of concerns and modularity in mind, and can help identify potential pain points when considering extension or modification.

回答4:

Be sure to break it down into areas of concern and address them individually. Areas I can think of to consider are:

1. Conformance to specified requirements (hopefully these are specific)
2. Performance/scalability
3. Code quality (including conventions you want followed)
4. Test coverage
5. Plugin/library licenses

It looks like others have addressed items 3 and 4. Since you're asking the question now (presumably after you've received the product) 1 and 2 will probably have to be manual process unless you have automated functionality tests already written (or want to automate tests so you can check future versions of what you bought). 5 is an item that is sometimes overlooked but can be VERY important. You probably don't want GPL code hooked in if you're going to be reselling this software. You need to review the licenses of every library included and decide which ones are compatible with your goals.

回答5:

To Understand your architecture, you can try JavaDepend it gives the possibility to query code with CQL, like SQL for database, with more than 82 metrics and many interactive views to go deep inside your design, architecture and implementation.