Previous generations dug holes, and later generations filled them up—how ​​to dig out those bugs

There are bound to be bugs when writing code. No one can guarantee that the code they write will be problem-free, and those bugs that have not been discovered become pitfalls for those who come later...

During this period, the company has been fully transformed to https, which involves the migration of domain names. The migration of domain names is not just about mapping nginx, but also requires the deschema of various codes and the migration of various components. It is a major operation! I see that Baidu's main site has also been upgraded to https recently. There should have been a problem during this period. It seems that it was rolled back once. The pitfalls they encountered should not be too many. It was just the upgrade of the www domain, not the entire network. The company has encountered many problems recently, both big and small. On the surface, they are pitfalls dug by predecessors, but in fact, the overall architectural thinking is lacking.

When we put down a project and move on to the next one, the things on hand have to be handed over to others to handle, or... no one is handling it anymore, but the code is still there. You may have quoted someone else's work, and there may be a big bug in someone else's code one day. Of course, the "others" here may also be you! We don't want to be victims, and we don't want to be perpetrators.

1. How to dig a hole

Digging holes is not an easy task. The plug-ins, components, and codes you write are likely to be used by many people. Your code will be run wildly in various business scenarios, and a bunch of testers will detect your bugs. Therefore, digging holes in the project is not an easy task.

So how to bury the pit? You can refer to the following solutions:

• Put a long, long code in a file without comments and without decoupling the program
• Put all the judgments in a layer of deep logic
• Temporarily add several global marker variables to the program, change the values ​​of the variables in many places, and use the values ​​of the variables in many places
• Don't consider changing scenarios, don't make real-time errors, and let him run according to the trajectory of your mind.
• Spreading different versions of the code everywhere without organizing unified documentation

If these solutions are not enough to dig a hole for you, I think the technical level of your team members is really too high.

Many times, we inadvertently leave hidden dangers. When what we write is used by others, the program needs to take into account more scenarios and more problems. At this time, we have to improve our code logic. As a result, the logic coupling is much higher, the code level is much deeper, and the probability of error is also increased.

Therefore, when designing a function or component, you must be clear about what you should and should not consider. Not everything is suitable to be added to the code. We are not making the overall solution of ExtJS, nor are we weaving a bottom-level operation library. We are just using a small amount of logic to integrate discrete and personalized businesses. The less logic, the better. Content that is not related to the core logic must be extracted!

2. Try to step into the pit

If digging a pit is a difficult task, then stepping into a pit is even more difficult. In fact, it can be said that the difficult part is not stepping into a pit, but discovering that you have stepped into a pit.

It is not easy to find the bug caused by writing the equal sign instead of the identity sign in a huge amount of files. You may enter other people's code domain when debugging. Facing other people's long and uncommented code, you may feel dizzy on the spot. What's more dizzy is that you still doubt whether this is the problem in the code. In teamwork, we trust our teammates by default. The code produced by teammates is fine and can be used directly. So once a problem occurs, we doubt ourselves more. It takes a lot of courage to question others, especially those mature frameworks and codes that have been used for many years.

So how to avoid pitfalls? We don't like pitfalls. Some pitfalls are hard to get out of, so we can only choose other solutions. Few front-end students write test cases for programs, and some students may have never heard of test cases. In the back-end (such as nodejs), the code without test cases is a pile of waste code. Except for yourself, others dare not use it. So what will the test case consider doing? Simply put:

• Write problematic code and make the program fail in the expected way. If it does not, the program has a bug.
• Write good code so that the program returns the correct results according to the normal process. If not, the program has a bug

The test cases should cover all the logical judgments in the program, such as if elseif else and other judgment logics. When our test code covers 100% of the logic, the pitfalls will be revealed.

The fatal weakness of those who set traps is that they seldom make abnormal judgments about the program. As long as they find the abnormal points in the program and try to trigger the abnormality in an alternative way, they will fall into the trap!

3. Fill the hole with force

First of all, filling the pit is a responsibility.

Finding a problem is the most difficult thing, and solving it is just a matter of time. When we identify a pit, the first thing we do is to tell others that there is a pit here, so don't step on it. But most people will add one more sentence: Don't step on it yet, wait until I fill the pit before you come back. I think this sentence is really heartwarming, and the care between programmers should be so naked. Although, sometimes, this pit is not dug by you...

After we have dug the pit, stepped on the pit, and buried the pit, we should look back and think about what role we play in the team, the pit digger or the pit buryer? This will definitely be beneficial to our growth.