jonm.dev

The Art of Writing Software

Code Artisan's New Year's Resolutions

Tags [ Cobertura, design patterns, estimation, Javadoc, resolution, TDD, unit test ]

Well, it’s a new year, so time to sit down and draw up a list of development resolutions. Without further ado:

  1. I will create unit tests for all my classes. There’s no excuse not to have at least some kind of unit test for each class that gets created; this at the very least provides a stratum on which other people can flesh out the tests to cover things that come up. This may not be full-blown TDD, but we could at least enforce this with some kind of unit test coverage tool like Cobertura.

  2. When debugging a defect, the first step will be to write an automated test case that captures it. Nothing is more annoying than a bug that can’t be reproduced. If you can actually get to the point where you can reliably trigger the bug, you’re probably most of the way towards finding the problem. Furthermore, in the process, you’ll have created an easy-to-run way to know when the bug is fixed. Since the test is automated, there’s a good chance that test will get re-run a whole bunch more times in the future of the codebase, making sure that once a bug gets squashed, it stays squashed.

  3. I will write Javadocs for all my public methods, except where they can be inherited from the Javadocs in an interface. This is just common courtesy to myself and the other developers. I’m cutting myself a break here, since one could argue that you really ought to document the protected ones too, but we’ll start small. This will also encourage definining interfaces and coding to them, as it saves a lot more effort if you can just Javadoc up the interface itself! For bonus points this year, write or find a tool to automatically check this.

  4. I will have explicit up-front design sessions before writing any code. I really don’t know why we don’t do this more than we do, other than we forget to do it. There are all kinds of good reasons to do this, like the fact that we always come up with better designs in a small group than we do by ourselves, or that this will help all of us become better designers by being present while good designs are being born. Or that a good design is usually easier to implement, and with all the hard work I’ve already set out for myself, I don’t mind finding resolutions that save me some effort.

  5. I will relentlessly learn to estimate better by considering my past estimating history when providing a new estimate. First step here is to actually look at my past history, so I know what it is! (Fortunately, we are already collecting the data for this…) Then possibly use techniques like those I laid out in a previous post about improving estimates.

Well, that’s it. Those are some pretty specific resolutions, which, I’m given to understand, makes it more likely that they’ll be adhered to. What are your coding resolutions for the new year?