How to divide a large Java project into smaller components

Question

We've trying to separate a big code base into logical modules. I would like some recommendations for tools as well as whatever experiences you might have had with this sort of thing.

The application consists of a server WAR and several rich-clients distributed in JARs. The trouble is that it's all in one big, hairy code base, one source tree of > 2k files war. Each JAR has a dedicated class with a main method, but the tangle of dependencies ensnares quickly. It's not all that bad, good practices were followed consistently and there are components with specific tasks. It just needs some improvement to help our team scale as it grows.

The modules will each be in a maven project, built by a parent POM. The process has already started on moving each JAR/WAR into it's own project, but it's obvious that this will only scratch the surface: a few classes in each app JAR and a mammoth "legacy" project with everything else. Also, there are already some unit and integration tests.

Anyway, I'm interesting in tools, techniques, and general advice to breaking up an overly large and entangled code base into something more manageable. Free/open source is preferred.

Answer 1

Have a look a Structure 101. It is awesome for visualizing dependencies, and showing the dependencies to break on your way to a cleaner structure.

Answer 2

We recently have accomplished a similar task, i.e. a project that consisted of > 1k source files with two main classes that had to be split up. We ended up with four separate projects, one for the base utility classes, one for the client database stuff, one for the server (the project is a rmi-server-client application), and one for the client gui stuff. Our project had to be separated because other applications were using the client as a command line only and if you used any of the gui classes by accident you were experiencing headless exceptions which only occurred when starting on the headless deployment server.

Some things to keep in mind from our experience:

• Use an entire sprint for separating the projects (don't let other tasks interfere with the split up for you will need the the whole time of a sprint)
• Use version control
• Write unit tests before you move any functionality somewhere else
• Use a continuous integration system (doesn't matter if home grown or out of the box)
• Minimize the number of files in the current changeset (you will save yourself a lot of work when you have to undo some changes)
• Use a dependency analysis tool all the way before moving classes (we have made good experiences with DependencyFinder)
• Take the time to restructure the packages into reasonable per project package sets
• Don't fear to change interfaces but have all dependent projects in the workspace so that you get all the compilation errors

Answer 3

Two advices: The first thing you need is Test suites. The second advice is to work in small steps.

If you have a strong test suite already then you're in a good position. Otherwise, I would some good high level tests (aka: system tests).

The main advantage of high level tests is that a relatively small amount of tests can get you great coverage. They will not help you in pin-pointing a bug, but you won't really need that: if you work in small steps and you make sure to run the tests after each change you'll be able to quickly detect (accidentally introduced) bugs: the root of the bug is in the small portion of the code has changed since the last time you ran the tests.