When building software, several things can be done to minimize errors, prevent future code from breaking, and adding to scalability. Ideally, your practices include some of the following.
TEST DRIVEN DEVELOPMENT
Test Driven Development, or TDD, is the practice of writing unit tests for a new feature before writing the actual code. You essentially write the unit test case, run it so it fails, then write the code to make it pass the test. You build up a set of these tests, which can be run automatically (i.e. Automated Unit Testing). Each time you make a significant change to your code, you can run these automated tests to ensure the test cases still hold, ultimately building a strong set of test cases, which will be useful for the lifetime of the software.
Personally, I find TDD extremely useful. Imagine the case where you are building a new piece of functionality. You may have subject matter experts or testers that can write several test cases for you to code against. Rather than finding out later that your code doesn’t pass these tests, you build your code around these tests. Your UAT has now become much easier.
AUTOMATED UNIT TESTING
Automated Unit Testing provides so many great benefits. Gone are the days when we would change a piece of code, and it would break other pieces of existing functionality. Regression testing now became much easier. With automated unit testing, you can know instantly if the new code you just wrote has broken another piece of functionality. Also, you don’t need to remember each exact step when rerunning tests – it’s all automated for you. There are several unit testing frameworks out there, including the popular xUnit, implemented originally for SmallTalk.
Without code conventions and standards, source code can become a little crazy. We have all inherited bad code at least once, and I’m sure most of us are guilty of creating non-perfect code at some point or another. Coding standards are vital in ensuring your code is maintainable by the next guy, understandable, and not to mention, scalable and bug proof. The easier the code is to read, the better the code will be, and the easier improvements and refactoring will be. Keep the code consistent and you reduce the cost of maintenance.
SOURCE CODE CONTROL
Source control is a fundamental to software development. When you write code, especially with other developers, you need source control to manage the process. Several good source code control systems exists today, including CVS, SVN, Git, Mercurial and Team Foundation Server. On top of a good source code control system, I always advocate having a solid infrastructure – dedicated machines for development, testing and building. You may want to look into IaaS (Infrastructure as a Service) to assist with your needs.
As developers check out source code from the repository, the code becomes more further from the original code, and more likely to break with other developer’s code. Continuous Integration, or CI, calls for higher intervals of check-in to reduce code conflicts. Basically, code is checked out of the source code repository, worked on, then checked into a CI machine which reflects the baseline code. If the code build successfully, its is checked back in to the repository. This minimizes the check-in of conflicting or “bad” code.
Build Automation includes automating a variety of tasks in the software build, including compiling, packaging and deploying the new code, as well as running tests and automating documentation. When your code needs to be deployed live as soon as possible, automating the build will reduce build issues, keeping the deployment consistent. This is very useful for continuous integration builds which are run often. If you are not automating your builds, you are subject to repeating redundant tasks and a higher of producing a bad build, which leads to more expensive and less robust solutions.
If you manage to set up an infrastructure with all of the above, you will be well on your way to producing consistent software.