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 also recoomend using the IDE's features to improve code quality. For eclipse this what i would do:

In the preferences java > code style > formatter - define your own format and add it. after that right click the project and source < clean up. Choose sustom profile and configure. There are plenty of things you can do here like code formatting cleaning up imports converting legacy for loops into enhanced ones cleaning up unused code and many more.

After that i would do the things other people here suggested as well like using checkstyle, pmd, findbugs and so on.

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

I've been through this process a few times now, I've found that the solution requires knowing the following:

• Will there be political unrest at the concept of fixing these things?
• Is there now an accepted standard for how these things should look / be formatted?
• Are there great test cases?

The political situation is the hardest to mitigate, fundamentally no one likes the idea of lateral movement, and going through the process of enforcing code formatting and naming conventions is very much a lateral movement. If you can come up with a solid set of metrics justifying your decision your lateral movement can be masqueraded as a forward movement. I've found that the best metrics here are along the lines of

"a consistent set of coding standards will result in: - 30% fewer bugs - 30% faster development - 80% lower maintenance cost - 100% of us coders will be far happier with this change"

Not just pulling these numbers out of the air is the trick. Be able to justify this.

Clearly there is no point starting this work unless you have buy in from the people currently adding to the project. Everyone must agree and begin retro fitting these ideals into the code that currently exists. Remember not everyone uses an IDE (e.g. I code all my java in VIM) and so you should make sure this format is dictated on a wiki for all to see (particularly new team members) and that the wiki page has downloads for the various editors in use.

Since it is very likely that we're not just talking about code formatting but also variable renaming and a change in patterns these affect the public api's of your classes so you really need to ensure you have a very stable set of test cases. If test cases are missing then you should always start from the outside in - model your tests such that they interact as your users do. Then you can go through and refactor with a degree of confidence. Once you have code that resembles your dreams you can go in and add tests closer to each object. Nothing is more painful that creating all your test cases, and then changing the API's and having to change all your test cases; every time I've seen that happen it results in a massive drop in test coverage.