When dealing with bugs, do you have a set of risk reduction policies that suit you?

 

How high is the risk of fixing a bug? Maybe, you will say, it depends on where the bug happened. Indeed, style issues in the UI Layer, errors in the background logical call layer, exceptions in the data access layer, changes to database-level functions or stored procedures ...... The impact of a bug may be minimal. Of course, it may also have a wide range of impacts, or even affectProgramArchitecture!

Despite the extreme situations, what we want to talk about today is the most frequently encountered bug in our daily work: Common Bugs that mainly occur at the UI Layer and data logic layer. How many times have we encountered such a bug that caused program exceptions and had to be modified due to ignoring its context association or not adding complete conditional verification and conditional processing?

This is not to criticize our "carelessness", but to explain the fact that, as a developer, when dealing with a bug, it is easy to "Ignore" the context associated with the bug because you are too concerned about the details of the bug; or do not fully understand the originalCodeWhen the work mechanism is complete, you can modify bugs, resulting in endless problems ...... Compared with the former, the latter has a wider impact. Therefore, in general, the Team Leader usually refers to the person who is most familiar with a function module to handle related bugs, this is actually the most common method to reduce risks.

Based on my experience on similar issues, the most mature and effective method is to complete our own bug modification process! Why? For example, my wife went to the hospital yesterday and showed me the doctor's documents. She found that the doctor was doing his homework according to the mature process, it can be seen how important a relatively mature process is for us to solve the problem!

Back to our topic, when dealing with bugs, do we follow a process we think is reasonable? I think everyone may have their own processes. Here is just a bit of my opinion for your reference:

(1) Open the bug list. You may use bug tracker or other bug tracking tools. This does not matter. Find the bugs you are responsible.

 

(2) handle bugs one by one. I prefer to copy the currently handled bugs to my own bug list document. I will add some personal notes, for example, the cause of the bug, the current progress, whether to re-verify or discuss with the product manager, etc., mainly to facilitate the complete tracking of the bug.

(3) carefully read the Bug title and detailed content. In general, the notes are very intuitive and I like them. If you have any questions, you need to immediately ask the tester who submitted the bug to confirm it, and pay attention to record the key data when the bug occurs.

(4) reproduce bugs on your own development machine. At first, you should try to follow the key steps provided by the tester to reproduce the bugs quickly, if you can infer the root cause of the problem through simple analysis, you can perform common bug verification.

(5) Enable the debugging function, reproduce the bug, track the code, and find out the cause of the problem. In general, if the exception is caused by the nonexistent object or incorrect value assignment, we can directly correct the problem, if data exceptions are involved, we may need to check the context of the Code that generates the bug, because the data provider or the handler may cause the final exception.

(6)After determining the root cause of the problem and modifying it, we need to verify ourselves! This step is so critical that everyone may easily ignore it!I often think that a bug is not difficult, so I just changed it. There should be no problems, and then I checked in. Later I guess the situation, the bug has been tested, and there is nothing left. If you need to submit it directly to the implementation or the customer's program, the consequences will be disastrous! Note that we should not only perform repeated tests based on the key steps of the original bug, but also conduct troubleshooting tests on the relevant procedures, this is because our modifications may affect peripheral functions. When we are not familiar with this function module, this risk is especially high and we must pay special attention to it.

(7) after the above step of self-verification is very important, we can submit our code. Here there is also a very easy-to-ignore detail: Fill in the bug remarks. This is the only way for others to understand your current submission of changes. If you are so careless or simply do not write anything, your modifications may fail and it will take a lot of time to trace the reasons, if the guy is far away, it will be even more difficult! Think for others, that is, for yourself.

(8) Provide relevant testers with information about your modifications in a timely manner, especially if the scope involved is large and requires investigation and verification, because although we did the test, there may still be some omissions.

(9) regularly check the bug list, track the bugs you are responsible for, and update your own bug list documents in a timely manner.

 

The above is the general process we adopt when dealing with bugs. Since we have written this process, we have encountered fewer problems due to incomplete bug modification, these problems were discovered during self-testing and exclusive verification, and they were handled before submission. In the past, I often felt very discouraged and doubted my abilities because of this situation. Later, I was enlightened by a test buddy, everyone will encounter a "Focus on" problem, because they are too concerned about technical details and ignore the logical association between the two sides, which is also the main cause of this problem. Therefore, we should try our best to reduce the consequences through a reasonable process, rather than blindly denying it ~

Hope to help you ~