Improving the Speech Server development/testing processes in near future
When first version of the product ships then it’s very natural initially to be extremely happy and celebrate, but soon you start thinking about how to improve things with the process or even better - how to use some cool technologies and tools to make everyone’s life easier. Here are a couple of things we’re planning to do in regards to preventing bugs and increasing the code quality in near future:
- From the personal point of view I finally decided to accept the fact that we live in the managed world. Majority of our server code has been written using C#. Most developers who move around in C# world know that FxCop is a good thing. One improvement we decided to do is to make sure that our system which processes every addition to code base will automagically run FxCop on resulting assemblies, compare the results from run against previously specified subset of FxCop rules, and bark on every code change which will cause some non-expected warnings to appear. This is one of the things which everyone can incorporate into their software development process. FxCop is available for download and has active community behind the tool. Couple of notes though: 1) you must spend time on figuring out what are the rules you care about, absolutes i.e., using all the rules is almost never a good thing; 2) you must make sure that everyone in your team agrees to these rules or that at least they’re enforced by The Powers That Be. If FxCop is lacking of some checks you desire or you want to use some additional standards then feel free to use
System.Reflection to do some additional checking ;-)
- The same thing for unmanaged static source code analysis tools: PREfast and PREfix. Again, there are number of similar tools provided by different vendors which everyone can incorporate into their development process. What we currently do is we run these tools on weekly basis on our code base and analyze the results. Some diligent people run them every time before changing any line of code, some people run these tools every time after they see somebody changing some lines of code, but we don’t have very formal and strict process yet. This will change soon.
- Test-Driven Development and unit testing is a thing everyone is talking about. For a months now everything I hear is that how TDD and writing unit tests will make world a better place. Everyone seems to be particularly discussing the "Test Driven Development in Microsoft .NET" book. Fine, I had to get a copy myself and read through it during last week. Now whenever I listen to 50 Cent I catch myself humming "NUnit!" instead of "G-Unit!" Well, let’s see how this TDD thing turns out to be. Is it a next silver bullet or not?
A curious reader may ask that why we haven’t implemented all these processes already? Like the slogan from Nike says - "Just Do It". Very simple answer is that because of basic risk analysis - changing the process in the midst of coding or lockdown demands resources, increases risk, and requires time (training, experimenting, increased development/testing estimates because of new requirements etc.) which nobody ever has. Ship which is an ice-breaker is good, but occasionally people dream of motor-boat and vice versa ;-)