Difference between revisions of "Defect Prevention"
(new) |
B michaelsen (Talk | contribs) |
||
(One intermediate revision by one other user not shown) | |||
Line 45: | Line 45: | ||
=== Refactor === | === Refactor === | ||
If code is difficult to understand or a continuous source of bugs, refactor it, until it is easy to maintain. | If code is difficult to understand or a continuous source of bugs, refactor it, until it is easy to maintain. | ||
+ | |||
+ | |||
+ | [[Category:Coding Standards]] |
Latest revision as of 12:56, 28 March 2010
Defect prevention means to avoid defects before and during coding, instead of finding and removing them afterwards.
Contents
- 1 14 Suggestions
- 1.1 Standards
- 1.2 Code Reviews
- 1.3 Personal Favourite Defect List
- 1.4 Expand Developer Tests
- 1.5 Use Unit Tests
- 1.6 Smallest Possible Steps
- 1.7 Warning Free Code
- 1.8 Dynamic Code Checks
- 1.9 Static Code Checks
- 1.10 Education
- 1.11 Make Quality a Goal
- 1.12 Plan for Quality
- 1.13 Analyse Bugs
- 1.14 Refactor
14 Suggestions
Some suggestions what could be done to prevent defects during software development:
Standards
Agree on and commit to a mandatory set of coding and design standards. Issues to be covered: Design, C++ usage, documentation, complexity, maintainability, interface design, error-handling, coding in general, use of standard solutions for standard problems.
Code Reviews
Establish regular code peer reviews. Use code you work upon. Use coding standards as reference and/or discuss what is really important to you. Change partners often and across domain-borders.
Personal Favourite Defect List
Keep a private list of your "favourite" bug causes and standard violations. Use that for continuous improvement.
Expand Developer Tests
When coding, test your code as if their would not be any QA later and all users' satisfaction would depend on you alone.
Use Unit Tests
Write unit tests and run them regularly. All unit tests have to pass.
Smallest Possible Steps
Adopt a habit of developing a feature in the smallest possible steps: The cycle of develop -> test -> develop -> test ... should be as short as possible, usually much shorter than a day.
Warning Free Code
The compiler is your first and free check against dubious code. Program such that there are no compiler warnings.
Dynamic Code Checks
Use Valgrind memcheck or similar tools to dynamically check your code against memory corruption.
Static Code Checks
Find and use tools that can statically check your code for correctness and maintainability. Currently most useful tools for this are not yet free/open-source but this may change.
Education
Educate yourself regularly. E.g. the knowledge about writing good C++ has changed enormously within the last 10 years.
Make Quality a Goal
Make the quality of your code just as important as the functionality. Indeed the quality is part of the functionality.
Plan for Quality
High quality coding needs more time than hacking. Plan for that. You get the time back by less bugs and easier code maintenance.
Analyse Bugs
Find out how bugs came into life, explore the reasons (inside and outside the code itself), change what caused the defects.
Refactor
If code is difficult to understand or a continuous source of bugs, refactor it, until it is easy to maintain.