Cleaning up a large, legacy Java project

Question

I\'ve been assigned to do some work on a huge Java project, and the influence of several iterations of developers is obvious. There is no standard coding style, formatting, nam

Answer 1

I find Eclipse to be an incredibly powerful tool for operations such as this.

A lot of people swear by command-line tools and modal-based text editors for programming but there are strong advantages of using a full IDE for major refactoring:

• Automatic, real-time compilation shows you errors as they happen and everywhere they happen. Just because you make a change and nothing in the class or immediate package breaks does not mean that you haven't created issues elsewhere. Red flags will go up the package tree in eclipse leading you directly to them.
• Graphical based renaming and moving. Renaming elements of your code can have an impact much larger than what you know. Eclipse will show you details of every instance of the element in question and how it will be changed by the rename.
• Automatic import management allows you to take the work out of dealing with ensuring all your imports are in order. Eclipse will automatically add imports as they are used and mark unused ones with action lightbulbs for one-click removal.
• Use code styles to ensure all of the source files use the same format for everything. Spaces, indents, new lines, parenthesis can all be formatted for you. This works as you create new code as well as for updating existing files.

In addition to Eclipse's toolset you might look in to utilizing other modern Java tools for ensuring your code is always functioning.

• Test suites allow you to constantly ensure any changes you make don't have a negative effect on the function of the project. If you are going to be refactoring a feature, write two or three test cases that demonstrate the ways it works. Make sure they run before and after any changes. This is the easiest way to spot problems before they become an issue.
• Use a tool such as Maven to assist with dependencies, testing, compiling, and deployments. Don't waste time doing any of the aforementioned tasks again. Focus on writing the code that does the work.

---

edit:

I also personally prefer Eclipse because I am the one doing the refactoring, not some automated tool that knows next to nothing about my code.

Answer 2

Start with the monolithic classes and break them up (greater than 500 statements excluding comments and lines with just braces). Introduce interfaces, then dependency injection.

Answer 3

My suggestion would be add something like Checkstyle to your build system. It's hard to get management to buy into the idea of doing a complete overhaul all at once. Design what you think are a good set of style guidelines and implement them in Checkstyle and add it to your build.

Then, require that all new check-in of code doesn't break Checkstyle. That means whenever you work on a class you'll bring it up to standards. It won't seem you're doing any extra work at all if it's just a little something you have to do before committing for a while.

Also, checkstyle plugins exist for Eclipse.

Answer 4

What I like to do in this situation is:

1. Firstly convert the project to use a maven build, so that I know what version the dependencies are.
2. This also gives me some decent code quality reports to use as a benchmark, including checkstyle, findbugs, pmd and code coverage.
3. And I (and many others) are used to this structure, so we know where to find the source, unit tests, resources etc.
4. If it is a large project then a maven multi-module project layout is probably the correct structure to use.
5. If it is currently one big-ball-of-mud, then that becomes the core module which can later be refactored into separate modules.
6. The standard maven directory structure provides place for, and therefore encourages unit tests.
7. The unit tests are a critical pre-requisite before refactoring can begin.
8. Establish a continuous integration build cycle using Hudson.

Answer 5

I had such experience. I agree with people that recommend maven build, eclipse, Checkstyle, refactoring of big classes etc. I understand that you cannot achieve full test coverage before your are starting to work. I'd recommend 1. reformat code in batch mode using checkstyle or similar tool 2. enable all reasonable warnings in Eclipse and refactor code that cause such warnings if this refactoring is trivial. In other cases put @SupressWarning and special TODO to come back to this code later. 3. use defect driven automatic testing, i.e. develop tests for module you are going to change.

Good luck!

Answer 6

It's a rather common task, not very joyful but neither a nightmare... It could be worse, if coded in other languages (Perl, PHP, C++, -gasp- VB... ); actually, Java is one the best for your scenario.

Get a decent IDE (Eclipse) and spend a good time understanding dependences and call cycles. It will take a long time to get familiar with everything, so try to make only small changes first.

When documentation is lacking, the IDE (and the static compiling) helps a lot to know who is using which class or method, and you can do refactoring quite confidently. But first try to identify in which layers/packages/classes is reflection used (explicitly by your code, or implicitly by your frameworks - eg. some getters and setters).

There are many books devoted to "Reengineering Legacy Software" and related issues.