< reading notes > Software debugging: The core of the problem-how to fix defects

Statement: The content of this document is mainly from the book "Software Debugging the way of cultivation", Paul Butcher, belongs to the reading notes. Welcome Reprint!

Fixing defects

For a good fix, not just to get the software running correctly, but to lay the groundwork for the future. Some of the scattered, without careful modification, will be the original concise design gradually disappear.

A good fix must simultaneously achieve the following goals:

• Fix the problem
• Avoid introducing regression
• Maintain or improve the overall quality of your code

-----------need to refer to the following rules----------

1. Remove obstacles

• Make sure everything starts from scratch, and when you're not willing to discard the changes made in the diagnostic phase, use the source control system.
• You need to do a quick review of your changes, and don't skip this step!
• Keep a record, or retain a copy of the relevant documents.

2. Testing

• If the development process includes test-first (test-driven) development, so you have an automated testing framework and a large number of unit testing tools to modify the source code, this method to avoid the introduction of regression can receive good results.
• Run existing test programs and prove that they are able to pass the
• Add one or more new test programs, which repair existing test programs
• Repairing defects proves that your fix has worked (previous failures no longer occur)
• Prove that no regression was introduced (previously passed tests have not failed at this time)

3, repair the cause of the problem rather than repair the phenomenon

The real work, the very time, side is the customer angry shouting, side is the project manager impatient face, you may be under pressure just let the flaw disappear, then carry on the next task, or because you analysis is not enough, also can cause only to repair the phenomenon, not the reason. No matter how bad it is, at least you understand the root cause and take a "sensible" approach to solve the problem quickly. But this approach is only one of the three goals of fixing the flaws, and the latter two are more important. At this time to play the spirit of academic sincerity, if you can not be sure that they really understand the crux of the problem, do not believe that your repair!

4. Refactoring

In recent years, with the increasing popularity of agile development methodologies, the most significant of the two technologies are widely used in automated testing and refactoring techniques. Refactoring is the process of improving the existing code design without altering its behavior, specifically referring to refactoring: improving the design of existing code.

Fixing defects often does not involve refactoring, but if there is a lack of experience, there is a duplication of the necessary changes made to modify the defect, which is not the case, and this is the principle of "don't repeat yourself" as described in the "Programmer's Way of cultivation".

Refactoring is more reasonable than refactoring before repairing defects, and of course, if the repair work is complicated, you may have to go through the process of repairing and refactoring again and again!

Remember: refactoring can not be changed at the same time the code function, also cannot repair defects!

5. Check In

To make reasonable use of the source control system, if a lot of errors are assembled together to check in, it will greatly reduce its role

Please adhere to this principle: one logical modification only one check-in

6. Code Review

Code reviews do not have a fixed execution time, sometimes involve colleagues in the initial stages of repair, sometimes just let them sign to confirm! This approach is an intrinsic part of the development process, and does not have to be seen as a formal debugging Method!

< reading notes > Software debugging: The core of the problem-how to fix defects