A 40-year-old programmer talks about the mentality of fixing bugs

[CSDN editor’s note] For programmers, if writing code is a manifestation of ability, then the ability to solve problems is equally important. The ability to troubleshoot problems may determine how far your career will go. Therefore, it is often joked that programmers are not writing code, but writing bugs. The author of this article is a Linux kernel engineer in his 40s. Based on his years of coding experience, he talks about how programmers should think about bugs.

Author| Song Baohua Editor-in-charge| Meng Yidan

Produced | CSDN (ID: CSDNnews)

The author is an old code farmer, already over 40 years old, and is still fighting on the front line to write codes and fix bugs, and there is no legendary 35-year-old crisis. After working for so many years, I have come into contact with many bugs in all aspects. I want to share my mentality about bug fixing as an old code farmer.

First of all, as a programmer, as long as you write code, there will definitely be bugs, unless the person does not write code . Therefore, we have to calmly accept this basic common sense. Anyone who brags that their code is bug-free is either a liar or a megalomaniac. But this does not mean that the more bugs, the more awesome. When we are programming, we must take various measures to avoid the occurrence of bugs. For example, pay special attention to:

1. The risk of multi-thread and multi-process concurrent access;

2. Handling of boundary conditions;

3. The basic idea of ​​defensive programming such as missing branch processing.

In the process of fixing bugs, the most important mentality is not to be impatient, as it is impossible to fix bugs in haste . Some students, the leader is very busy with the progress, so he changes one line to the east and one line to the west, trying to try his luck to fix this bug. The author has worked for so many years, and basically never encountered such luck.

Code is the most logical thing in this world, and there will be no luck against logic . The more difficult the bug is to fix, and the tighter the progress of the bug, the more calm the mind should be. Repeatedly review the code logic, review the relationship between its own modules and other modules, and review the global multi-threaded data access and timing logic. Simply put, the clearer you can sort out the code you care about and the logical relationship between your code and other codes, the more likely it is to fix this bug. So I really have no idea, what should I do? Replay logic! I’m running out of ideas, what should I do? Recovery logic.

I was quite impressed. When repairing the logic of communication between wayland’s client UI and server weston, the crash was Qt App, but the actual problem was the timing of wayland messages between weston and app. At this time The only way is to clarify the protocol of wayland, what kind of message should be sent by client and server when, what kind of message will cause the window to be destroyed, etc., we can only calm down and analyze repeatedly. Look at the captured wayland socket messages between the client and server one by one, and analyze whether the timing between the client and server processes is disordered according to the protocol. There is no other way.

Taking a step back, even if a person really “fixes” a bug by trying blindly, how does it help personal growth? What rules have we extracted? What logic has been clarified? Can you tell me why it was fixed? Such recklessness will not grow.

In the process of fixing bugs, try to refresh your brain . Sometimes when the head is numb, the train of thought will be short-circuited. Why not go out and breathe fresh air for five minutes. It may seem like five minutes wasted, but in fact, it is possible to gain an idea during these five minutes. What I personally often encounter is that I feel numb sitting in front of the computer, and I feel more anxious because I am eager to fix bugs. However, the baby is after school, and I have to go out to pick up the baby. On the way for about ten minutes, I found this bug and I can fix it when I come back. So, sometimes, slow is fast. It seems that ten minutes of picking up the baby was wasted, but in fact, the ten minutes of fresh air sobered the brain, so the contribution of fixing this bug may have to be counted on the baby.

When writing code, you may wish to add some assertions/BUG_ON and the like, and leave a printout at an uncertain position . The world of code is full of magic. You think that when you reach a certain position, a must be equal to 1, but when the code runs, it happens to be equal to 2. why? Because there are bugs in the code, it is the bug that makes it not equal to 1. Then we can try to add a BUG_ON (a!=1). For any bug, the earlier it appears, the easier it is to fix. BUG follows the law of “early death and early rebirth”. If you make a mistake at point a and die at point b, c, or d, it is obviously difficult for you to trace back to point a, but if you are at point a, you can detect it in advance Potential problems, and actively reduce the difficulty of fixing this bug. Especially after the product is launched, there may even be bugs that cannot be reproduced after repeated tests in the laboratory. The BUG_ON and printing of these abnormal points can help prompt the direction of repair.

To fix bugs, it is necessary to establish the breadth and depth of knowledge in the business domain . As a Linux kernel engineer, such as changing the code of memory management, page fault, swap, etc., it seems that only a small part of the code of a module has been changed, but because this code is too low-level, it may be related to many other kernel components such as scheduling , file system, VFS, page cache, etc. are all inextricably linked. At this time, it is difficult to fix bugs without understanding the breadth and depth of the kernel. Therefore, we must not underestimate the matter of fixing bugs. Some people are at a loss for the same bug for a month, and some people solve it in two days. What do you think is the reason for the poor 28 days? Without him, you know or don’t know business knowledge, not the programming language itself.

Therefore, the mastery of C, C++, Java and other languages ​​absolutely cannot separate the distance between programmers. What can open the distance between programmers is the mastery of the business imposed by the programming language. Language is the most basic thing. For example, every American can speak English, but every American’s business level is different. Some people buy for 0 yuan, and some have Jobs. As a programmer, can you show off that you are proficient in C language? This is useless, it is meaningless to tell an American that he speaks English well.

The text and pictures in this article are from CSDN