12 key steps to fix a programming bug

Boss: So, how long do you need to fix this bug? Inexperienced programmer: Give me one hours? Up to two hours? I can fix it right now! Experienced programmers: So, how long will it take me to catch a fish?! It's hard to know beforehand how long it will take to fix the bug, especially if you're not even acquainted with the code. James shore, in the Art of Agile, has made it clear that you need to know the problem before you can fix it. The reason we can't accurately estimate the time is because we don't know how long it will take to find the crux of the problem, but only by knowing that we can reasonably estimate the time it takes to fix the bug. However, this time I am afraid the lily is cold. Steve McConnell once said: "Find the problem-understand the problem-this is the work of programmer 90%." "A lot of bugs just need to change one line of code. But it takes a lot of time to figure out what's right in the back-like when we're fishing, we have to know where to bait, when the fish are easy to hook up and so on. There are four types of bugs: the first easy to find easy to repair, the second difficult to find easy to repair, the third easy to find difficult to repair, fourth difficult to find difficult to repair. The most tragic is the last type, not only "looking for, desolately cool obsession", even if finally arduous hollows, can only be involuntarily scratching over there, but sigh a long way its repair far XI. You can say that unless it's a freshly baked code, you'll find bugs just like elephant-confused and don't know what type of bug belongs to. Find and fix bugs do you know what it means to "find and fix bugs"? Yes, it's debugging! Constant commissioning, countless times of commissioning! Paul Butcher through a lot of work, summed up the following structured steps: 1. Clear purpose. Check the exception report carefully to determine if it is a bug, find out all kinds of useful information to find the crux of the problem and reproduce it. Check again to see if duplicate reports occur. If repetition occurs, look at how the relevant people have handled it. 2. Preparation-Find the right code and use the exclusion method to clean up the work area. 3. Match the test environment. This process can be skipped if the customer is manipulating the computer configuration. 4. Clarify the purpose of the code to ensure that the existing testing tools are all right. 5. OK, now it's time to go fishing--reproduce and diagnose errors. If you can't reproduce, you can't prove that you've done the repair work. 6. Write a test case, or catch a bug with a ready-made test case. 7. Go to Repair mode-make sure you don't affect any other parts. However, before you start a repair job, you may want to do the refactoring work, because it's the only way you can do the code with no scruple. It also ensures that you won't be adding any new bugs after you have returned to the test. 8. The wholeManagement code. Make your code easier to understand and secure with step-by-step refactoring. 9. Find someone else to review, Lookers onlooker sees most. 10. Check the repair process again. 11. Try not to start from the main line to check whether these bugs affect other branches. Merge these changes, handle the differences in the code, review all the reviews and tests, and so on. 12. Think. Think about what's wrong and what's wrong? Why is your fix working? Where will this type of bug appear? In the book "The Pragmatic Programmer", Andy Hunt and Dave Thomas also pointed out that "if a bug takes a lot of your time, make sure you understand why." In addition, there is a need to think about how to draw lessons and not cropper on similar issues in the future. And, do we use the method, the tools used to improve the place? and the impact and severity of these bugs. Find a bug or fix a bug, which takes more time? Perhaps it takes more time to build a test environment, reproduce the problem, and test the bug than to find bugs and fix bugs. But for a small number of obvious bugs, it's easy to find them--but they might not be as good as they seem. In the book "Making Software", there is a chapter on "Most of the sources of software vulnerabilities", Dewayne Perry analysis that it takes longer to find bugs (including understanding bugs and reproducing bugs) than fixes. Studies have shown that most bugs (almost 3/4) are both easy to find and easy to fix: 5 days or less (this is based on large-scale real-time systems through the heavyweight SDLC, extensive review and testing of data). But there are also very nasty bugs, even if you can easily find it, still have to "painstaking" to repair. Discovery/Repair Repair time <=5 days repair time >5 days can reproduce the problem 72.5% 18.4% difficult to reproduce or not reproduce 5.9% 3.2% so if you bet that you can fix the bug very quickly, in most cases you're right. But when you lose the bet, then, hey, it means you have * annoying. So, next time, boss ask when can fix the bug, don't be silly to answer "can be done immediately". Free to receive the Lamp Brothers and original PHP tutorial CD/"Detailed PHP" Essentials Edition, details of the website customer service: Http://www.lampbrother.netPHPCMS two times development http://yun.itxdl.cn/online/phpcms /index.php?u=5 Development Http://yun.itxdl.cn/online/weixin/index. php?u=5 Mobile Internet server-side development Http://yun.itxdl.cn/online/server/index.php?u=5Javascript Course http://yun.itxdl.cn/online/js/ Index.php?u=5cto Training Camp Http://yun.itxdl.cn/online/cto/index.php?u=5

