- Attacking the Dragons
- Implementing a Test Harness
- Making the Changes
- Test, Code, Test
- Any Dragons Remaining?
- Conclusion
Any Dragons Remaining?
Do these metrics, and associated refactoring techniques to eliminate them, remove all sources of bugs? Of course not! Other sources of bugs are harder to find mechanically:
- Unclear variable names
- Method names that are not descriptive
- Multithreaded code
- Highly optimized code
- Code in complex domains that are hard for outsiders to understand
Some of these risks are controllable. Naming problems can be caught through peer review of code, where colleagues are able to assess each other's code honestly for sense. Sometimes the problems are egregious, such as using x as a variable name where something else may be more descriptive. Other approaches are inherently risky; for example, using multithreaded code, or code that has been highly optimized (often for good reasons!), or code in domains that are inherently complex. In these situations, you should have very high test coverage, but there will always be some residual risk, regardless of refactoring or any other means used to control the risk.