This is going to be a very subjective post. I’ve been writing C# applications in .NET since the first release back in 2001 and I feel very comfortable with the language and the tool chain. I’ve certainly seen my fair share of ‘how not to write C# applications in .NET’. Although I am a C# programmer, this post is primarily about software engineering so it’s going to applicable to Java developers as much as it is to C# developers.
There are many critical aspects to software development, such as: knowing the API’s / frameworks that your code is calling (i.e. the .NET Framework), knowing your programming language intimately, knowing the runtime environment i.e. operating system / VM, having a reasonable application design, understanding the problem domain etc.
As important as these aspects are, they don’t play much of a part in the decisions concerning how to go about writing a software application per se – for example, how do I decide what classes will be in the application and how those classes will interact with one another? It’s difficult to answer these kinds of question as every scenario is different, but we can certainly define some useful rules to guide this creative process.
Shipping is without doubt the most important feature of software development. Without it, we may as well be monkey’s sitting at a keyboard trying to write the complete works of Shakespeare by pressing keys randomly for all the difference it would make to the world. Code that is badly thought out and badly constructed has a much lower chance of shipping on time, if at all.
Arguably the second most important goal of software engineering is to create a maintainable legacy. Don’t get me wrong, writing green field code is great…what’s not to like about it? But very few developers manage to avoid maintaining an existing code base during their career. In fact, the reality is that we probably spend most of our career maintaining a legacy as opposed to creating a brand new one from scratch. Therefore, creating a maintainable legacy should be one of the most important characteristics of any code we write. Next year, you could easily be maintaining my code or I could be maintaining yours.
So let’s kick off with a top ten list of essential software development rules:
- Every domain class should have a battery of tests for the behavior it is exhibiting (data only classes need no tests)
- Avoid inheritance unless there really is an *is a* relationship between derived and base
- Always practice interface based development with ‘Inversion Of Control’ provided by a container (i.e. Castle)
- Always follow the ‘Single Responsibility Principal’ when writing any domain class
- Refactor as soon as a class begins to sprout lots of private methods
- Always write clean (hygenic) code and that also applies equally to all unit tests \
- Domain classes, should always have an interface defined for them
- Domain classes should never new up other domain classes
- Avoid static classes as they defeat testing
- Only ever check in code that has been reviewed by a peer
Well, that’s the list for this blog post. I’ll be going into the details of each item in the next post, so stay tuned!