[Turn] predecessors dig pits, posterity pits-how to dig out those bugs

    When we drop a project and switch to the next one, the things at hand are going to be handed over to others, or. No longer someone to deal with, but the code is still there, do not make you refer to other people's things, guarantee no one day someone else's code burst out a big bug, of course, the "others" here may be you! We do not wish ourselves to be victims, nor do we wish ourselves to be the perpetrators.

 

Write code inevitably out of the bug, no one can guarantee that their code is not a problem, and those who have not been excavated out of the bug, it became a later people laugh and cry of the pit ...

This period of time the company full HTTPS transformation, involving the transfer of domain name, the migration of the domain name is not nginx do a mapping on the finished son, there are various code to the schema, the removal of various components, is considered a major surgery! I see the recent Baidu main station also upgraded to HTTPS, during the period should have a problem it, seemingly rolled back once, they encountered the pit should not be too much, just www domain upgrade, not the whole network. Recently, the company has a lot of problems, the size of the problem, the surface is dug by the previous pit, is actually the overall structure of the lack of thinking.

When we drop a project and switch to the next one, the things at hand are going to be handed over to others, or. No longer someone to deal with, but the code is still there, do not make you refer to other people's things, guarantee no one day someone else's code burst out a big bug, of course, the "others" here may be you! We do not wish ourselves to be victims, nor do we wish ourselves to be the perpetrators.

1. How to dig a pit

Digging a hole is not a simple thing, you write out of the plug-ins, components, code, it is likely to be used by many people, various business scenarios to run your code, a bunch of testers to detect your bug, so it is not easy to bury in the project.

So how do we bury the pit? You can refer to the following scenarios:

• Put a long, long code in a file without comment and decoupling program
• Put your judgment in a layer of deep logic.
• The program temporarily joins several global tag variables, changing the values of variables in many places, using the values of variables in many places
• Do not consider the changeable scene, not real-time fault tolerance, let him follow the trajectory of your brain to run
• Distribute different versions of code everywhere, without organizing unified documents

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

Many times, we have inadvertently left a hidden danger. When you write something that is used by others, the program needs to take into account the situation will increase, the problem will become more, this time we have to improve their code logic. As a result, the logical coupling degree is much higher, the code level is deep, and the probability of error increases a lot.

So when designing a function or component, it is important to consider what should be considered and what should be considered. Not all things are suitable for the code to add, we are not doing extjs this overall solution, is not to weave a bottom-level operation library, just with a small amount of logic to integrate discrete, personalized business, the less the better, and the core of the content of the logic must be drawn out!

2. Slam the Hole

If digging a hole is a very difficult job, it is even harder to step on the pit. In fact, it can be said that the difficulty is not stepping on the pit, but found themselves stepping on the pit.

In a pile of huge files to find out "because of the equal sign as a constant equals" caused by the bug, it is not easy, you may be in the debugger when you enter someone else's Code field, the other people huge long and no comment code, estimated the spot on the faint, more dizzy is, I'm still wondering if this is the problem with the code. Teamwork, we are in the heart of the default trust teammates, teammates output code is no problem can be directly used to use, so once the problem, we suspect more self, questioned others need a lot of courage, especially to question the mature framework, with many years of code.

So how do you step on the pit? We do not like to step on the pit, some pits into the jump will not come out, and finally can only choose other solutions to deal with. There are few test cases where front-end students write programs, and some of them may not have heard of any test cases at all. And in the back end (such as Nodejs) no test case code is a bunch of scrap code, in addition to their own can be used, others simply do not dare to use. So what do the tests do with the regular consideration? Simply put:

• Write the code that has the problem, let the program go wrong according to the expected error, if not, the program has a bug
• Write code that is no problem, let the program return the correct result according to the normal process, if not, the program has a bug

The test case should overwrite all logical judgments in the program, such as if ElseIf else, the logic of the judgment should be covered in. When our test code covered 100% of the logic, the pit was out of place.

The fatal weakness of buried deceptive is that there are very few exceptions to the procedure, as long as you find the anomaly in the program and try to trigger the anomaly in an alternative way, you step on the pit!

3. Force pits

First, pits is a responsibility.

Finding the problem is the hardest and solving the problem is only a matter of time. When we confirm a pit, the first thing is to tell someone there's a hole here, you don't step on it. But it is better to make a few more words: You do not step on, waiting for me to fill out the pit you come again. I think this sentence is really warm heart, the procedural ape between the care should be so naked. Although, sometimes, this pit is not for you to dig.

When we dig a good hole, after the pit, and then bury the pit, back to think about what role they play in the team, digging the pit or burying the person? This must be conducive to growth.

[Turn] predecessors dig pits, posterity pits-how to dig out those bugs