general

I had a relatively long post put together about writing code and how important it is to be consistent with your teammates. I had a few paragraphs on maintaining style, architecture, and keeping the essence of the code you’re working with. Instead of going through that, I boiled it down to a few basics that I run into often.

Keep the style consistent

If you have a corporate style, follow that.  Otherwise, the Snoracle code conventions are mostly your friend. I always have to grit my teeth when someone abuses this.  If the project is written in a K&R style, don’t complain when your Allman style classes get reformatted.  Checkstyle does a really good job at automating this at check in time, while the major IDEs have very good formatting tools.

Maintain the architecture

If the project you’ve been asked to maintain is straight JSF, don’t slam in your favorite DI framework because that’s all you know. Take the time to look through the code and get to know it.  Maintain the architecture whenever possible.  When it’s your turn to decide the design, you can do it however you want. Until then, it’s helpful to stick with the groundwork that’s already present.  Keeping the architecture clean is a huge advantage when it comes time for refactoring or retrofitting for missed requirements.

Follow the spirit

If a class has only 5-line methods, don’t slam in a 50-line monstrosity.  When all the parameters are declared final, take note, and do the same where appropriate.  If the class is immutable, don’t add javabean setters.  In other words, don’t redecorate your friend’s house when you stop by for a visit.  For good or bad, a lot of developers feel strongly about code they initially created.  If someone else isn’t considerate of the spirit in which that code was written, feelings can fray and productivity can plummet.

Don’t break things

Before you check your code in, make sure it compiles and passes all of the unit tests.  Continuous integration helps this situation, but you can save yourself embarrassment and the wrath of your coworkers by making sure things are ok before committing.  If you don’t have unit tests for your stuff, now is the time to write some.  No one likes a broken build, but it’s even worse when broken code ends up on your machine straight from source control. Developers have a hard enough time tracking down their own bugs.  Adding to that burden and making them fix yours is not appreciated.

It seems we’re in a trend shift that’s deeper than has been experienced in the last several years. I don’t have any empirical evidence for this, but it’s the general direction people seem to be taking when I talk to them. Perhaps it’s a “something different” syndrome and most of these new technologies will never gain any mainstream traction. For my purposes, I’m dissatisfied with my current stack and actively looking to make some changes. Is anyone else feeling the need for a context switch to something different? What other products are likely to get dumped and become just a found memory?

2010 should be an exciting year for Java developers. 2009 had several events that the Java community will look to capitalize on.

• Oracle buys Sun – This was the big one, but it’s still stuck in a bit of limbo.  Regulators from the European Union are blocking the deal, but signs appear to indicate that it will be worked out soon.  The major sticking point seems to be MySQL and the issues around how an Oracle acquisition affects the competitiveness of the database market.  Hopefully something gets finalized as Oracle appears to be the best Java steward available outside Sun itself.
• Java 7 pushed back  – Due to JCP infighting, Java 7’s release date got pushed back. It’s been discussed to death, but apparently that opens the door to add closures to Java 7 as announced at this year’s Devoxx. The change was mostly welcome from the blogger community. In reality, it shouldn’t change the lives of most mainstream developers right away.  I’m sure there are several shops that are still living on 1.4, but Java 7 is something to watch as the milestones get released and people get familiar with the new features.
• JEE 6 released – This is a fun item that I’ve been spending time with recently.  CDI, bean validation, JSF 2.0, and a whole host of other features look to simplify and improve the life for enterprise Java coders.  Sadly, it’ll take a bit of time for most shops to push new application servers into production.  However, the bleeding edge shops should gain some needed productivity traction through the use of a standards-based stack.
• JVM languages rule – 2009 was the year of the JVM language.  From Scala to Clojure to Groovy, there was something for everyone and it’s a welcome change in my book.  Several of these languages have been around for years, but they are just now becoming accepted among the masses.  2010 will continue that trend.  I look forward to the days of hacking on some Scala and having my coworkers being able to help me out.

In short, 2010 is going to be a great time to be a Java developer.  The language is evolving, developers are improving their skills, the tools and IDEs are outstanding, and the work is interesting.  I’m looking forward to the challenges and opportunities that this year will bring.  Here’s to an awesome year, as a Java developer, in 2010!

With a new year, I’ve decided it’s time to do something, I’ve been putting off, and start a development blog.  I’m going to be posting my thoughts on software development, Java, JVM languages, database issues, open source software, what makes a successful project, and whatever else happens to come up.  Generally, I’m going to try and talk about “code goop”.  Basically, the ugly, nasty, and sticky parts of writing software that people don’t tell you.  I’m hoping to post lots of code samples and promote some languages, tools, and libraries that don’t get enough exposure.  On the flip side, I’m looking for others to help expose me to some of those things that I might be missing out on.  Shoot me an email or drop a comment and we can explore the world of software development a bit.  I love what I do and I want to build on that here.