After reading Robert Simmons article on O'Reilly and the sample online chapter, I'll definitely be buying Hardcore Java. I don't agree with everything he says, but I like the way he thinks about dealing with existing code: Use a Stronger Compiler for Your Code What I read came across more as "use Eclipse or IDEA", which is fine ;) The example given could be caught with unit tests or even better with a field prefixing convention (instead of the this keyword): public class SomeClass { private String itsSomeValue; public SomeClass(final String someValue) { itsSomeValue = someValue; } public void setFirstName(final String value) { itsSomeValue = itsSomeValue ; } } My convention is to use 'its' for fields and 'the' for statics (some folks use 'my'). I've never managed to self-assign a field. Just look at the code above - it's not hard to spot the problem. This also has the advantage that accessing object fields directly looks painfully stupid (as it should). I believe some folks deal with this issue by only accessing internally through get/sets. However, if your developers depend on diffs instead of code documentation to determine problems, then you probably already have a serious problem in your code base. No, documentation isn't worth that much in legacy code - I'd consider taking it too seriously as a project risk. Diffs are worth more. Behaviour is worth more again. We have problems when the tests don't pass after checkin, not whether we're leveraging documentation. Remove Commented-Out Code Absolutely. But we should ask why that comment is being left there at all. Blocks of commented-out code can be a sign that version control isn't being used well. Replace Listeners with Weak Listeners Ok. A problem I've seen with Listeners is thread safety, not so much GC. I tend to replace listeners with queues (but this might not be practical in Swing code). So here are seven other ways to improve legacy code, some of which are not so cheap (think of them as investments ;): Get the build under control This is job number one - own the build. "Builds in my IDE" doesn't count. Use ant or makefile to build code, not an IDE. Once we've got the build down, then we can start levaraging the IDE, but the build process has to be IDE independent. Dysfunctional build and deployment processes are a good way to derail legacy maintainance projects. Do a one time reformat over the class and check in. Thereafter stick with that format. Most time spent with legacy code is spent reading it, so make this comfortable. Prefix fields. See above for an idiom that works. Buy a copy of Martin Fowler's Refactoring. Buy two copies, and read both of them. It's Money well spent. Refactoring has a list of techniques that can help get the structure of the code under control before we start changing behaviour. As important as the techniques, are the discipline and shared vocabulary this will bring. Search the code for empty catch blocks. Get them them to output something. But we need to be careful about getting them to throw on the production system until the consequences of doing so are understood. Start taking version control seriously. The biggest mistake we can make with version control is to treat as a glorified backup system - it's not called backup control for a reason. Version control, used well, is there to help us manage change, not just to have a place to dump the source code. Build a habit of frequent checkins and updates - keep checkins small - you're doing it right when comments seem superfluous. Add unit tests. This is especially important when upgrading legacy systems that have no regression tests. There are two approaches here. We can do this against the existing code base first to capture its actual behaviour, on the basis that what a functioning production system is supposed to do is another matter again to what it actually does (which also gets the nub of the issue with taking comments seriously - comments don't execute). But if we have clear requirements for new behaviour we can think about capturing that in tests instead and working to make the code pass them - we'll go faster of course - but if the code base is shall we say, intricate, this won't help with the non-local bugs we introduce, however unintentional :)...
Previous Topic
