|
boss: So, how long will it take you to fix this bug?
Inexperienced programmer: Give me an hour? Two hours at most? I can get it done right away!
Experienced Programmer: Let’s put it this way, it takes me as long as it takes to catch a fish? !
How long it will take to fix the bug is difficult to know in advance, especially if you are new to the code, the situation will be even more confusing. In the book "The Art of Agile", James Shore clearly points out that if you want to fix a problem, you must first know what the problem is. The reason why we can't accurately estimate the time is because we don't know how long it will take to find the crux. Only by knowing this, can we reasonably estimate the time it will take to fix the bug. However, I am afraid that the day lilies are already cold at this time. Steve McConnell once said:
"Find the problem - understand the problem - this is 90% of the programmer's job."
Many bugs only need to change a certain line of code. But what requires a lot of time is that we have to figure out what is correct later - just like when we are fishing, we have to know where to put the bait, when the fish is easy to take the bait, etc. It is said that there are four types of bugs: the first type is easy to find and easy to fix, the second type is hard to find and easy to fix, the third type is easy to find and hard to fix, and the fourth type is hard to find and hard to fix. The most tragic thing is the last type. Not only is it "searching and searching, but it is desolate and desolate", even if it finally breaks through the stone after all the hard work, one can only scratch one's head and scratch one's head involuntarily, sighing helplessly: "The road is long and long." ". It can be said that unless it is freshly released code, looking for bugs is like a blind man feeling for an elephant - you are confused and don't know which bug type it belongs to.
Find and fix bugs
Do you know what “find and fix bugs” means? That’s right, debugging! Constant debugging, countless debugging! Through extensive work, Paul Butcher summarized the following structured steps:
1. Clarify the purpose. Carefully review the exception report to determine whether it is a bug, find various useful information, discover the crux of the problem, and reproduce it. Check again for duplication with the report. If duplication occurs, see how the people involved handled it.
2. Preparation - Find the correct code and clean up the work area with elimination.
3. Match the test environment. This process can be skipped if the customer is working on computer configuration.
4. Clarify the purpose of the code and ensure that everything is working properly with existing testing tools.
5. Okay, now you can go fishing - reproduce and diagnose the error. If you can't reproduce it, you can't prove you've done the repair work.
6. Write test cases, or catch bugs through ready-made test cases.
7. Enter repair mode - make sure it doesn't affect any other parts. However, before you start fixing it, you may want to do the refactoring because only then you can mess with the code without fear. And post-regression testing can also ensure that you will not add any new bugs.
8. Organize the code. Make your code easier to understand and safer through step-by-step refactoring.
9. Find someone else to review it, the authorities will be confused by the onlookers.
10. Check this repair process again.
11. Try not starting from the main line to check whether these bugs will affect other branches. Merge these changes, handle differences in the code, review all reviews and tests, etc.
12. Think. Think carefully about what went wrong and why? Why does your fix work? Where else would this type of bug appear? In the book "The Pragmatic Programmer", Andy Hunt and Dave Thomas also pointed out that "if a bug costs you a lot of time, then you must find out why." In addition, we also need to think about how to learn from experience and lessons so that we will no longer stumble on similar issues in the future. And, is there anything that can be improved in the methods and tools we use? and the impact and severity of these bugs.
Which one takes more time, finding the bug or fixing it?
Perhaps the time required to set up a test environment, reproduce the problem and test the bug is far more than the time to find the bug and fix it. But for a small number of obvious bugs, finding them is easy—but fixing them may be less than ideal.
In the book "Making Software", there is a chapter that mainly discusses "the source of most software vulnerabilities". Dewayne Perry analyzes that compared to repairing, the time required to find a bug (including understanding the bug and reproducing the bug) longer. 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 heavy-duty SDLC, extensive review and testing). But there are also very disgusting bugs. Even if you can catch it easily, you still have to work hard to fix it.
Discover/Repair Repair time<=5 days Repair time>5 days
Can reproduce the problem 72.5% 18.4%
It is difficult or impossible to reproduce 5.9% 3.2%
So if you bet that You fix bugs quickly, and most of the time you're right. But when you lose the bet, then, hehe, it means you are *in trouble.
So, next time, when the boss asks when the bug will be fixed, don’t stupidly answer “it will be done soon”.
Receive LAMP Brothers’ original PHP tutorial CD/"Essential PHP in Details" for free. For details, please contact the official website customer service: http://www.lampbrother.net
PHPCMSSecondary development http: //yun.itxdl.cn/online/phpcms/index.php?u=5
WeChat development
Mobile Internet Server Side Development http://yun.itxdl.cn/online/server/index.php?u=5
JavascriptCourse http:// yun.itxdl.cn/online/js/index.php?u=5
CTOTraining Camp 5
|
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
