Jess Chadwick: Coder: Some Tips on How to Ship Better Code

In my last post, I pontificated about the notion that Real Software Artists Ship. But, I’ve got to take a step back and admit something – in that last post, I was full of crap. I don’t really consider myself an “Agilist”, nor do I come anywhere close to zealousness when it comes to TDD, but I have studied (and I use the term loosely!) these movements for some time now and have been able to adopt many of them into my daily grind with varying degrees of success.

Here are a few that I have found to be the most helpful in shipping better code as fast as possible:

Use Source Control: I originally didn’t have this listed until I just had to come back and put it as #1. I’m sure you’re already doing this, but I just had to say it anyway. If you’re not using source control, rabid hamsters will eat your code and there is nothing you will be able to do about it.
Unit Testing: What always seems to put everyone off about TDD is the seemingly massive amount of additional work it adds and the recommended zealousness with which you should adhere to it. To those complaints I say: obviously it’s more work; nobody’s debating that. But, the ROI of having a suite of regression tests alone is so incredibly high it’s foolish not to do it. And, if you’re not keen on religiously adhering to a rigid development process of not writing a line of production code that’s not backed by a test, then don’t do it… but do seriously consider writing a least a few tests to cover the core functionality of your code at the very least. Writing tests after the fact still offers significant value, even if you aren’t enjoying the full suite of benefits that true TDD has to offer.
Continuous Integration (CI) Builds: At my last job, a co-worker of mine had a sticker affixed to his monitor proudly proclaiming, “It works on my machine.” Even if you are a one-developer shop, the benefits of ensuring that you’ve successfully checked in everything needed to build your application are pretty spectacular. This is so very relevant because the fact is – one-developer shop or not – your production environment is not your machine (or if it is, well, I don’t know what to say… stop doing that? Pretty please?). Also, if you’ve already got unit tests from the previous recommendation, you’ll find that they go very well with CI Builds. They go beyond a simple compile to actually running your full suite of unit tests to exercise your code every time, which is a huge win!
Your company doesn't have a CI server? Start one on your machine!
This may sound contrary to avoiding the "Works on my machine" syndrome, but having a continuous integration server - even on your own machine - is better than nothing at all. You may not be testing your code on another machine, but you are at least testing it outside of your working codebase and are still being forced to run your unit tests at regular intervals, which are pretty big wins regardless of which machine they're occurring on.
Use a Refactoring Tool (Liberally): There are some bugs that just never should have happened. I’m talking about things like existing code that worked until you wanted to move it into its own method – now it’s throwing null reference exceptions because you forgot to initialize that one variable. Now, I’m not saying that these tools will eliminate this scenario, but they will make it much more difficult to achieve. Interestingly enough, for those tools like ReSharper that provide suggestions on improving your code, I found that I was actually learning some things while using these tools! At the very least, those suggestions really help encourage you to clean up your code by acting like a nagging parent - “are you really going to leave this like this? This is embarrassing!” Course, unlike the nagging parent, if you disagree with the suggestion, you can just turn it off!