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, naming conventions or class structure. It's a good day when I come across a class with Javadoc, and unit testing is a happy daydream.

So far those of us on the project have been "blending in", adapting to the existing convention of whatever class we're working on, but the time is coming to impose some order and consistency.

It's a daunting challenge, and I'm looking for any advice people might have on such a task. Are there any strategies that have been particularly effective, or pitfalls to look out for? Is it even a good idea to try?

Edit to add: I don't want to give the impression that the project is bad - it is in fact solidly designed and largely well-written. It's just feeling its age and the inevitability of maintenance...

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

You can use a tool to impose a common format on the source code in the project. Aside from that, see Michael Feathers' Working Effectively with Legacy Code (where "legacy code" is defined to be "code without unit tests"), which describes how to gradually turn legacy code into fully-tested and -testable code.

Answer 3

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.