Test-driven development"

Link: http://blog.sina.com.cn/s/blog_5d90e82f0101kfnd.html

Many companies, including Google and coverity, now like test-driven development ). It works by writingProgramWrite the automated unit test at the same time ). InCodeAfter modification, these tests can be run in batches to avoid unexpected errors.

This is not a bad idea. I also used many tests in Kent's compiler course. They are indispensable in Compiler development. The compiler is an extremely sophisticated program, and minor changes may cause major errors. Therefore, compiler projects generally contain a large number of tests.

However, improper use can greatly reduce the development efficiency. When I developed Python Static Analysis for Google, I hardly used any tests. Although the members in the group urged me to write tests, I knew that it would only reduce my development efficiency. This program was overturned several times during the past few weeks. If I write a test at the beginning, these tests will be in the way and will prevent me from greatly modifying the code.

The final result is that within 12 weeks, I wrote something that Google's team had to do for several years. The technology in this thing is still in the world's leading position. Even companies dedicated to static analysis software such as coverity cannot compare the code quality. According to their development method, it is impossible to make this thing within 12 weeks.

Another side effect of the test is that it gives many people a blind dependence on the test. After the program is changed, the test is run once without errors, and the code is correct. However, the test does not guarantee that the code is correct, even if it is completely "overwritten. Overwrite only indicates that your code has been tested, but it cannot be determined under what conditions it has encountered. If the actual conditions are different from those during the test, problems still occur during the actual operation. The only reliable way to ensure that the Code is correct is to use rigorous logical reasoning to prove its correctness.

Many people write programs based on phenomena, but cannot precisely analyze the logic of the program. Therefore, they often modify programs to "conquer the symptoms ". If there is a program problem, they can see where it is wrong and do not understand it very well. Just change it so that it will not make any mistakes, and at most run all the tests again. Or add some new tests to ensure that there is no problem next time.

The result of this approach is that there are a lot of "special cases" and "patches" in the program ". Press a "worm" and the other worm will come out again. In the end, the program cannot meet "all situations ". In fact, programs that can "cover all situations" are often much simpler than those that can "cover special situations. This is a strange thing: the more you can do, the less code you need. Maybe this is called the "beauty" of the program ".

the beauty program cannot be supplemented by repair. It must perfectly conform to the essence of things, otherwise there will be the above situation, there are many exceptions that cannot be repaired. Programmers and painters are almost the same. If a painter stays at home one day, he cannot draw any good things. The same is true for programmers. It is difficult to write good code when they are sitting at home and facing computers. You must observe things and look for "inspiration" instead of modifying code. When modifying the code, you must use the "Eye of the soul" to see the things behind the code. This is also why many brilliant programmers do not use debuggers. They just looked at the code with their eyes, closed their eyes, and there was a flow of information in their minds, so they often changed their hands to the right place.