Thursday, September 11, 2008

Developer Best Practices

I have been thinking about best practices at work and I am going to throw some ideas out here to help me think them through and to get feedback if any of you have opinions. This isn't complete or well organized - I am just trying to get the juices flowing.

  • Do not rely on this or any other document to provide a complete list of best practices. There are too many and some seem too obvious to talk about. You are a professional software developer - learn the craft. Don't stop learning. Aim for 10X.
  • There is no absolute "best" way to do anything. Think about what you are trying to accomplish. Be pragmatic.
  • Design applications in layers. Create distinct modules or blocks of function. Design the module interfaces first. Design by contract.
  • Write unit tests.
  • At a minimum write unit tests of the module interfaces.
  • Ideally write the tests before the code.
  • If you are about to debug something, stop and write a unit test for it first.
  • Don't create mindless unit tests. The auto-generated ones your IDE makes for you are only stubs - don't rely on them for coverage.
  • Inject your dependencies as a matter of course. This will greatly simplify unit testing. You don't actually need a framework for this - understand the underlying principle instead.
  • Keep stuff in source control (SVN, CVS).
  • Do frequent check-ins.
  • Comment your commits.
  • Don't rely on your IDE to do builds. Have a build script instead.
  • Have an independent environment where the build script can be run that is not a developers personal space. Ideally do continuous integration here, but at a minimum regularly check that this build environment still works. Use this environment to build releases.
  • Settle on a layout style for the team. It doesn't matter which style, it matters more that everyone is consistent. Or just agree to do it differently and people can reformat their code using their IDEs. But make sure everyone is on the same page.
  • Optimize code only when you have demonstrated that it performs poorly. Make a regular practice of benchmarking modules. Run the benchmarks with your unit tests so you know when something gets really out of whack.
  • Employ regular peer review of some kind. Internal code reviews. Pair programming. Whatever works for your team. This is how bad code gets found and how developers learn to get better.
  • Also have occasional external code reviews that involve more than just the immediate team.
  • Encourage zero code ownership. Everyone owns all of the code. Anyone can change/fix anything. Any bug is everyone's responsibility.
  • Use tools regularly to check for common bugs/problems. If I review your Java code I am going to run findbugs on it - so you should too.
  • Minimize local configuration information in multi-tier applications. An ideal java midtier should only need to know one thing - a JNDI datasource from which all other configuration information can be derived. An ideal thick client should get global configuration from the server.
  • Always close resources. Take full advantage of try/finally blocks.
  • Don't reinvent the wheel. Use the core libraries of your platform. If you are writing in Java and you think you need to write a sort routine, or a string to date routine, or an array copy routine: STOP. Find good adjunct libraries and use them.
  • Have a well thought out strategy for handling exceptions and logging. All errors should be logged, preferably once. The log entry should give enough information to lead back to the root cause. It should be time stamped. It should contain a stack trace if applicable. It should have a context appropriate message that can be understood by someone not intimately familiar with the code.
  • Do your release cycles faster. I don't care how fast you are doing them now, go faster.
  • It is OK to make pragmatic short term compromises in your code, but make sure you go back and fix them very soon. Do not fall into the boiled frog trap.
  • Eat your own dog food. If you design a service interface and never actually use it, chances are it will actually be unusable in some way. The same for a user interface.

Recommended reading for best practices:
Any thoughts out there?

David

No comments: