Java best practices

Wed, 24 Aug 2005 21:49:18 GMT

At Evolution we hold regular special interest group meetings that are open to our staff and clients. Last night, I ran a session about Java best practices. It's an age old topic, yet somehow still remains to be timely. Here's an interesting quote from a blog entry entitled On Software Engineering (emphasis mine).

On August 4 we had a session on software engineering. The aim of the session was to share knowledge and experience about the way we develop software and to discuss the importance of doing it a certain way. After the break we had a workshop that briefly touched the different parts of the software development process.

The quiz on current real-life practices raised a lot of discussion. While we all recognize the importance of source control, automation of manual tasks, testing, documentation and proper incident management many of us fail in a proper implementation of these practices.

I think that's so true and ultimately it comes down to time pressures. Of course, it's easy to argue that it's worth a small upfront effort to adopt some of the practices (particularly automation) since they will reduce time pressures further downstream. But that's a different story.

Anyway, the session itself consisted of two parts. The first was an overview of the key best practices we adopted on my last development project, including automated unit testing with JUnit, continuous integration with CruiseControl and project blogs with Pebble. The second half was more of a roundtable discussion about other best practices that we are using, including code quality checking (e.g. Checkstyle and PMD), code coverage (e.g. Clover) and automated acceptance testing (e.g. HttpUnit and Canoo WebTest). As a consultant, listening to other people talk about their own projects and experiences is part of the fun and we had quite an engaging session, washed down with a beer or two.

If anybody is interested, a copy of the slides can be found here and if you have any questions, just fire me off an e-mail to the address on the last slide.

If you're in London and would like me to come and talk to your team about this sort of stuff, again, just drop me a mail. I'm looking forward to our .NET session on the same topics.

JSIG

Fri, 15 Jul 2005 16:10:06 GMT

Now that I'm back in London, I popped down to the London JSIG this lunchtime for The Need For Speed: The Ins and Outs of Profiling Java Applications, presented by Enerjy.

First up was a look at their Java profiling application. Enerjy told us that in a study commissioned by Sun Microsystems, 50% of projects didn't even consider using a profiling tool. I was quite surprised by this figure - 50% actually sounds on the low side! Aside from whether profiling is estimated and planned for, typically profiling is only used in a reactive rather than proactive manner. I'm still unsure how profiling can be become a normal part of development, but I suspect that other things need to happen beforehand. For example, continuous performance monitoring still doesn't happen on many projects and without this, it's hard to figure out whether you need to profile your app. Some good advice was to get the non-functional requirements agreed as soon as possible.

The other thing that Enerjy said is that memory leaks are one of the primary causes for poor performance in J2EE applications. While this is true to some degree, I think that there are far bigger contributors, such as incorrect transaction boundaries or too many remote calls. Anyway, back to the profiling tool, it does the usual memory/CPU/thread profiling and has some nice hooks into IDEs such as Eclipse. Seemed to work well although I didn't really understand what this provides over other tools like OptimizeIt, JProbe or JProfiler. Oh, and no support for Mac OS X. ;-)

After lunch (good pizza!) was a look at their code analysis tool. The presentation started with a look at why many software projects fail and the key factor that came out here was poor code quality. Again, this is one contributing factor, but (IMHO) there are other bigger factors such as a lack of process, failing to manage client expectations, failing to manage changing requirements, etc. One good point made was that code reviews are not typically estimated and planned for. I agree with this.

Back to the tool and, again, it seemed to work well and integrate nicely with Eclipse. From a functional perspective, the tool lets you perform automatic reviews to ensure that code is following well known and industry accepted standards. Here, we're talking about things like the Sun coding conventions and some of the best practices highlighted by books such as "Effective Java". So how does it compare to the open source tools like PMD, Checkstyle and even the rules built into Eclipse itself? One example cited was that you can write your own rules as Java classes. Well, you can do that with PMD. I think that rather than waiting for the inevitable question, it may have been better to address this head-on. For me, there's nothing revolutionary here, although both tools will be interesting to keep an eye on. Overall, an interesting session.

Simon Brown - checkstyle tag

Java best practices

JSIG