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!
--------------------------------------------------------------------------------------------
Defect Priority
How to combine defect repair with software development?
How can I estimate the time it takes to repair a bug?
How do you ensure that the project does not fall into the countless bug fixes described in the people's Month myth?
- Defect Priority
- To adopt the early-morning defect repair principle, and based on the following two principles
- Testing, code review, and user use of software throughout the development process
- Bug fixes due to any other things
- Early bug fixes can significantly reduce the reliability of software runs, and estimate the approximate time needed to fix your test plan, and post-repair will only accumulate technical debt and do not know when to fix them and end the project.
- Low quality is contagious, so there is no broken window, software development and maintenance, is a continuous and entropy struggle process
2. The thinking of debugging
- Debugging first is a psychological activity, to maintain a healthy debugging mentality. Naïve to say, "No broken window" can be understood as only absolute perfection in the case can be achieved. Anyone who has participated in software development knows that defects inevitably, no matter how hard, there will always be omissions, how to solve the problem?
- The most effective mode of thinking is a pragmatic 0 tolerance strategy, very close to 0, but with a pragmatic mentality to achieve, although we are far from perfect, but can be in the right way unlimited access to it.
- When adopting a window-free strategy, it is necessary to distinguish the defects from the characteristics, the defects are the unconscious behavior, the others are the characteristics, the two may be the same for the customer, but the software developers must distinguish and understand that the features are the software running according to the design, the problem is not as serious as the defects.
3. Solve quality Problems yourself
- Without a panacea for quick fixes, the only reliable way is to fix all defects. Stop developing flawed programs, build experiments, and observe results
- Separate the dirty code from the clean code, and if there is not enough time to fix it, block it first, and a change in this method is to use the sandbox model to solve the problem module.
- Fault classification, update the defect database regularly, and ensure that the newly created project has a reasonable priority.
- The flaw blitz, that is, in a day, a week or a period of time, in addition to repair defects do not do any other work, but to be cautious to use, lasting a long time, it is easy to fatigue, and exhausted everyone.
- The special group, which is the deformation of the Lightning defect War, allows a group to gather together for a limited period of time to solve special quality problems.
4. Focus on reducing risk when repairing already released software
- A real fix may involve a wide range of software refactoring, deep-seated software system changes, the lack of a normal test of the release process and the balance of the various links, it is difficult to determine the chain reaction, and ultimately make things worse rather than better. So when a patch is implemented, a palliative is probably a better choice.
- Do not assume that the fix has been inadvertently modified, and be aware of the potential problems associated with such a fix, so check as many as possible.
- When the development version undergoes a full release cycle, get a complete, fixed fix.
5. Backwards compatibility
- Determine that the code itself is fixed without causing compatibility issues, and regression testing can pinpoint backward compatibility issues
- To resolve compatibility issues, if the confirmation causes compatibility issues, then you need to follow the choices below
- Provide a migration approach
- Implementing a Compatibility Mode
- Provide alerts
- Do not fix defects
6. Heisenberg defect
- If you run the software under the debugger, try adding the piles directly to the source code.
- The Heisenberg flaw relies on certain uncertainties, which in itself is a clue that turns your task into finding a way to gather the information you need, which has minimal impact on the software and ensures that it doesn't change its behavior.
- The only way to fix the flaw is to be more careful than usual to make sure you really understand the underlying causes.
- Don't assume you've fixed it before you know the nature of the problem. For example, if a defect is caused by an unborn variable, how do you figure out how the unborn variable causes the behavior you observe? To initialize it to a bad value, can you see the expected result? Performance flaws looking for bottlenecks, which specific area of code limits overall performance accuracy can be analyzed
7. Embedded Software
- Debugging embedded software is tricky, not complicated, but the environment in which it resides.
- With embedded Debugging tools, you can remotely debug via network cable, or through JTAG,SW online debugging, one of the challenges is the parallel development of hardware and software, usually repairing a hardware problem is more difficult than solving software problems.
- The painful process of extracting information, an LCD, LED, serial port and other means as a communication channel is often enough, although not convenient, but it is possible.
- Use Logic Analyzer as the Software debugging tool to solve timing errors!
8. Errors in third-party software
- Don't be too quick to blame, third-party is just code, also contains flaws, first of all to doubt their own code.
- If you are satisfied that the third-party code is defective, then submit an error report and wait for the resolution, there is no other way, preferably in the short term shelve the problem.
- Open source code, many open source projects only get limited attention, so its open source does not mean the end of debugging.
- One of the great places in the open source community is the increased quality, free software, and often high-quality technical support is also free of charge. Therefore, learn to seek help effectively.
< reading notes > Software debugging: Debugging from the big picture-0 tolerance strategy
