Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

The full Java life: Interview with Carlus Henry, independent consultant

On old and new approaches to Java programming

By Matthew Heusser, JavaWorld.com, 09/26/12

  • Print
  • Feedback
.

Page 3 of 6

Matt Heusser: Has your coding style changed over the past few years? What new techniques are you using?

Carlus Henry: At my last customer engagement, one of the developers on the team challenged me by sharing some of his insights from Bob Martin's Clean Code (see Resources). For a while now I've been noticing applications that have abandoned the idea of object-oriented development. Too many times I have seen, and unfortunately written, code that was nothing more than a humongous "controller" with business logic. I have written classes that were several hundred lines long. That is not object-oriented development. Classes should rarely be that large, and if they are then there should be a good reason for them to be. Instead, they should be broken up into multiple classes where each one is responsible for a certain aspect of the functionality. I do make exceptions to this rule for data access objects, where SQL may be stored for retrieving information from the database.

Another technique that I have been using is to employ code generators. While I have tried to use code generators that are readily available, I have found that I am more successful with ones that I write myself. The main reason for this is because I can create a code generator that adheres to my customer's standards. Writing a code generator is extremely simple and can be a lot of fun to do. This may be one of those "tricks" that I use to achieve a lot of productivity within a limited amount of time. I have written code generators for queries, controllers, unit tests, and fixtures. They have definitely worked very well.

Using a local database has also proved to be invaluable. Too many times I have worked for organizations where the database is shared between the developers, a continuous integration build, and/or one of the testing environments. This, in my opinion, is a recipe for disaster. Having a database that you can run both your tests and application against drastically increases your productivity. With this, you don't have to worry about coordinating your own local development and testing with anyone else. You don't have to worry about "logically" sharding the data, so that no one corrupts the data that you are working with, and you don't inadvertently corrupt data that one of your team members (or even worse, your customer) may be testing with.

"Another technique that I have been using is to employ code generators. While I have tried to use code generators that are readily available, I have found that I am more successful with ones that I write myself."

Even with all of this, the absolute biggest thing that has drastically changed the way that I develop software comes from using a distributed version control system (DVCS). Most of the engagements that I have had, my customers have all used Subversion. I started becoming extremely interested in DVCS when a friend who works at SourceForge started using Git. We would get into conversations about Git, and I am sure that for a while I drove him crazy.

  • Print
  • Feedback

Resources