Having high code quality is critical to your business. If you have bugs regularly showing up in your production code you’ll be hurting your reputation with your customers. In addition the development team be spending time that had been planned on implementing new features fixing those bugs which hurts your business. Here are five things your development team can do to help ensure high code quality.
Write Automated Unit Tests
Unit tests validate the code is correct at the function level. They test that each function in the production code behaves properly in all positive and negative test cases. Code coverage tools which show the percentage of the code that’s been executed during a test run can help ensure that all the positive and negative test cases have been covered. Automating the unit tests enables you to run those tests whenever there is a change checked in to your code base to ensure that change hasn’t broken anything. Automated unit tests are the first level of safety nets for catching any bugs in your software before they get out to the field.
Practice Test Driven Development
If writing automated unit tests is critical then the process you use for writing the tests is just as critical. Test Driven Development has the developer write a failing unit test before writing the production code. Then just enough production code is written to make that unit test pass. Once the tests are passing the developer goes back and refactors the test and the production code to make sure they are clean and following best practices and standards. This is a short 2-3 minute cycle of changes that ensures that every line of production code has unit test code to back it up. It also ensures as the developer is working that no other unit tests have been broken by any changes made to the production code. Lastly, it helps drive to a clean and minimal implementation by having only enough code written to pass the currently failing test and refactoring to make things clean as you go.
Use Static Code Analysis Tools
Static code analysis tools should be run by the developer on all code changes before they are checked in to the baseline. Static code analyzers can identify things like memory leaks, exceeding array bounds, and uninitialized variables which may be missed by the unit tests. Some teams go so far as not allowing anything to be checked into the baseline that doesn’t have a clean run of the static analysis tools.
Automated Integration Tests
Automated integration tests verify that the code works properly when integrated into the real system. This integration can happen at multiple levels. At the component level where the classes and functions are integrated into a single executable binary or library and at the system level where a set of components are combined to make a system. This can then be layered into systems of systems for complex products. The automated integration tests should verify all the inputs and outputs at all of these levels. The tests should mainly be verifying that things are “wired up” properly. At the component level this ensures that class and function pointers are created and assigned properly. At the system level this verifies that network and other communications paths between components have been setup properly. After new features have been successfully integrated in the overall system the automated integration tests become the automated regression tests to validate that future changes haven’t broken anything in the integrated system.
Peer Code Review
The final thing that should be done is a code review of the changes by other members of the team. This should include the code for the unit tests, the production code, and the integration tests. The code reviewers should be checking to make sure the code meets the team’s standards for formatting and best practices, looking for common errors like memory leaks and uninitialized variables, and verifying the code implements the intended logic for the feature. Code reviews are a very important tool in ensuring the quality of your code base as there’s nothing better than having another set of eyes look through the changes. And it also helps keep other members on the team in sync on design issues and best practices.
These five items are what I’ve found have been the biggest contributors to maintaining code quality in the software projects I’ve worked on. I’ve always found that the biggest pressure is to just get the code out the door as fast as possible. But if you take short cuts and skip practices that ensure code quality you’ll end up with bugs showing up in front of your customer which can be worse than a feature being late. If you establish these practices in your team and account for them in your initial schedule estimates you’ll have a lot more confidence when the production code goes out to the field that everything will go smoothly.