As bigger a project is, there’s more chance for quality issues. What can be these quality issues: too many bugs, too long runtime, too high memory usage, difficult to understand/difficult to modify coding style etc. These quality issues are making normally the user of your program unhappy, and the development slower. Unfortunately you can never rid of all quality issues, but you can avoid most of them by follow the points below. Of course these solutions costs a lot of time, but it is better to do this kind of effort in time and not loosing the same time with bug fixing.
Before the start of development you need to make sure, that it is 100% clear what your program should do. Here of course you need to think about things like compatibility of the requirements with each other or if it is possible to implement all the requirements, are there any certain hardware limitations?
To be honest most of the bugs are coming from simple misunderstandings: the customer had a different understanding about the functionality as the developer.
That’s why it is good to document these requirements in a clearly written form and let the customer read them and accept them.
If the requirements are clear still don’t start with the coding. First think about the solution, about how it should be implemented? Which algorithms needs to be used? Which part of the code will be reusable? Which libraries could be used? How will the different components and classes communicate with each other? And so on…
With this kind of planning you can already find and avoid a lot of possible problems in the future. Document your design in form of text and/or UML diagrams.
- Coding guideline
If multiple developers are working on the same code always have a coding guideline which defines the coding style to be used (naming of functions and variables, usage of brackets etc.). So that your code will have a uni formic style which is well-readable.
Do design and code reviews with other team members. They can find easily the mistakes in your way of thinking or in your code code. Don’t let any piece of code be merged without a review on that.
Use static code analyser tools. These tools are analysing your source code without running it. They can find a lot a of possible problems, like uninitialised variables, never satisfied conditions, unreachable code part and so on. They can check for coding style as well.
Implements unit test for you code. A good unit test is running fast and testing a small piece (unit) of your code. Unit tests can help to be sure in case of every change that you didn’t brake the already working functionality and they can help to understand for other programmers what your code is for, since from the unit tests they can see what is the expected behaviour.
Don’t forget to do some higher level tests and the you component or system as it is. This is basically a black box test, so you are not doing it based on the code, but based on the requirements. You can easily check if your component is fulfilling the requirements or not. Think always about corner cases as well. These tests can be manual of automatised as well. Automatised tests have the advantage, that you can run the tests later any time.
Setup a continuous integration server with a CI system (like Jenkins), let it to run nightly builds and check your code in case of each new change. You can integrate the static analyser and the automatised tests as well. So that after each commit you have an automated feedback if your software is working fine or not.
Track you already found bugs in a bug tracker system (ex.: Mantis). For each bug document how to reproduce them and how it is differing from the expected behaviour. If one bug got fix you can shortly document the way of solution of the fix as well, to avoid the same kind of bugs in the future. With this method you will never forget about any bug.
To be able to maintain the performance of your software you need to measure it’s runtime regularly. For that you can any profiling tool. With this method you can also discover the part which are using the most runtime. You need to check the memory usage of your tool also. For such purposes always try to define the scenarios which are the most difficult one from computation point of view.