What techniques you use to ensure code quality?
Pairing? Code reviews? Design? Documentation?
What helps you creating extensible quality software?
What techniques you use to ensure code quality?
Pairing? Code reviews? Design? Documentation?
What helps you creating extensible quality software?
In terms of code quality in my last .NET project I used StyleCop to keep my code clean. http://code.msdn.microsoft.com/sourceanalysis (i'm sure theres equvalents for other environments)
It took a while to get into the constant reminders to follow it's rules but I have to say the code is really clean as a result. I'm planning to use it again in the hope that it will become second nature after a while.
I don't think it takes anything away from the creative aspect of programming, it's more a way of reminding you to keep up the quality of your code. For most of the rules I was happy to use the defaults provided but you can provide your own too.
I'm a fan of code reviews but find that they are unpopular or percieved as too time consuming.
I basically make sure my code is easy to read and close to the domain as possible. I believe there's no better documentation than the code, so if your code is easy to read then you'd have an easier time maintaining it.
As for actual engineering practices, I personally think that it depends on the size of the team and what kind of software you're writing. What you probably will want to have in any software project you're working on are:
For code, I would recommend keeping it simple as much as possible. Tests are also a great way to specify requirements and as soon as you can write tests you definitely should. Once your code is tested enough, you should be able to refactor your implementation to keep it as simple as possible on many different levels.
One thing that is essential if you're working in a team would be code reviews and making sure that the written code is actually readable and understandable code. The less time you spend trying to figure things out means the better your code is translating the solution.
Code quality starts when you interview someone - you need the right people with the right skills and (most important of all) ... the right attitude.
I've tried pairing, code reviews all sorts of stuff but if you don't have the right people - its pointless.
A stable team helps as well - if you have a high turnover of staff it means that you will find it more difficult to get the right people.
Once thats sorted out all the techniques above help. Developers who read books about development always seem to turn out better code.
Use tools as well: static analysis, coverage reports etc.
I think, in order to be able to answer this question, you have to be more specific on what you mean by 'code quality'. :) Is code-quality the amount of code that conforms to some style-guideline ? Is code-quality the amount of code that has no defects ?
For me, code quality is readable code, that conforms as much as possible to the style-guideline that is used, and that has as little as possible defects.
In order to achieve that, I try to:
The most important element I have found is to make sure that everyone on the team understands what is expected of them quality wise. This can be communicated via pairing and code reviews (that also cover unit tests) as well as task prioritization - do we spend time refactoring the server (it really needs it) or adding the new feature, how much time to spend on integration testing etc. After that point everything comes for free and the team members tends to push each other on.
The real killer is how you get the best out of reviews, pairing etc as this will vary from team to team. You really need to get buy in from the team and let them arrive at an implementation that works well for all concerned.
Code quality is a factor of if you understood the requirements for the new code correctly, are using sufficient programming skills with appropriate time available to get a meaningful results.
I know this sounds like weasels words, its not meant that way.
Bottom line:
- **good requirements**
- good skills in the solution domain (programming and design)
- and enough time to turn out a good results
Plus a desire to create quality software.
All of these of course have trade offs depending on the situation. Hopefully you have them all.
The Principle of Software Quality
The best way to improve productivity and quality is to reduce the time spent reworking code. Reworking can take the form of changes in requirements, changes in design, or debugging.
Here is what we have as our rules:
Defence in depth:
http://successfulsoftware.net/2008/07/09/using-defence-in-depth-to-produce-high-quality-software/
main()
or the equivalent.Besides other things, we've used the following techniques/mechanism to make sure that our product is of high quality:
This worked out really well as we get only very few bug and error reports, even though our product is used by quite a few users. I wrote an article explaining the above mentioned techniques in more detail on our software quality blog: