Shulou(Shulou.com)06/01 Report--

This article is to share with you about how to write code without BUG, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

On September 9, 1947, Commodore Grace Hopper used Mark II and Mark III computers for research in the computer laboratory of Harvard College. Her team tracked down an error on Mark II, which operators found to be caused by a moth drilling into Mark II's relay. The team cleared the moth and everything returned to normal. The staff at that time recorded such a log: "First actual case of bug being found." this famous event was like Pandora opening the magic box, and from then on, the programmer's world was full of bug.

The first bug in the world

Among the roles I have played, there is a position called Development Manager, usually referred to as DM. I remember that in a secondary development project based on one platform, because there were so many bug, we almost spent a whole milestone cycle to debug, so I have a new explanation for this DM: Debug Man.

No one likes bug,bug, which means error, uncertainty, overtime, delivery risk, etc. No matter how negative words are piled up, they are not redundant. Find any developer who has experienced in one or two projects and ask him about the memories of debug. The atmosphere is like going to the grave.

The nerves of developers are also often very sensitive to bug. There's an interesting joke-- "how to give a bug back to a programmer"--

You can't just say to him, "this is not right. Is there a bug in your program?" If you want to say so, you will be directly resented: "you can't fucking use it!" .

You can put it another way: "Hey, it doesn't seem to be right here. Am I doing it wrong?" At this time, the programmer's heart thumped: "Shit.. is not my code has bug?"

After years of practice, it's interesting to find that sometimes, when a bug is discovered, the person who made the mistake jokingly extricates himself: "who hasn't written bug, Windows and bug?" I've used this excuse before, and it feels good, just like: Messi can miss a penalty, and it's understandable that I didn't get an empty goal.

But the truth is... This logic won't stand up to scrutiny.

The Windows operating system, a giant project that has been installed for more than 30 years, is estimated to exceed the population of the earth, and its complexity can only be guessed. According to the information released by Microsoft:

Windows 95 has about 1500 lines of code.

The amount of Windows XP code is about 4500 million lines.

The amount of Windows Vista code is about 5000 million lines.

The code volume of Windows 7 is 5000 + million lines.

Take Windows 7 as an example, more than 50 million code, 23 groups, a total of more than 1000 development team. The bug produced on this scale can be compared with a guy who works in the office for a day and writes 200 lines of code, and then makes a lot of bug and messes up the project. Finally, with an understatement, "Microsoft also has bug", aren't you ashamed?

So I did not use this sentence later, so excused, the level is too low. Let me talk about the alternative later.

In order to fight against bug, people have invented a variety of tools and means, from methodology to production tools. More and more advanced IDE, complex code review system, from unit testing to integrated debugging, coupled with beta version, trial, public beta, and so on. The goal of all these is to eliminate bug. But the existence of these dazzling solutions proves a tragedy: human beings are so fallible.

If everything has both positive and negative meanings, then the positive energy of bug is that it has created a large number of job opportunities, thus maintaining social stability.

So, why can't we always avoid the emergence of bug? Can we stop bug?

The answer is, of course, no. Because that way, isn't it too comfortable for programmers? It doesn't fit the position of being miserable. Moreover, in the world we live in, the more we shout for extinction, the more widespread it will be. Like flies, mosquitoes, pollution, crime, war, to name a few.

According to common sense, code written by more experienced hands is more likely to pass at one time, such as more thorough thinking, more sophisticated judgment and handling of exceptions, more accurate grasp of boundary conditions, and so on. So we may fantasize: as long as we are careful enough and work hard to hone our skills, by letting some of the farmers become sophisticated first, and then achieve common sophistication, we can finally achieve the great liberation of developers all over the world to work together to eliminate bug?

Unfortunately, this is only a way to address the symptoms rather than the root causes, because bug has a class. Veterans have relatively few bug, but few low-level errors, they will also encounter bug, and their bug is often a difficult factor N.x, which does not occur at the code level, mostly at the business level, or even at the requirements design level, or directly some irresistible factors (have you ever done a government project? ). In short, cute new people show funny, the uncle has the uncle's short circuit, the old pole will also have his own Waterloo.

The origin of the concept of bug indicates its inevitability. The first bug in the world was a moth. Who would have thought of this script? In a sense, bug is an unforeseen error that can be predicted and prepared in advance, which is called exception, and try catch is their friend.

For the reason why bug occurs, the famous Dutch computer scientist Edsger W. Dijkstra has a classic saying:

If debugging is the process of removing software bugs

Then programming must be the process of putting them in.

This is an alternative to the excuse mentioned above, "Windows also has bug." :)

Imagine that when you write down a sentence of code from scratch, at any moment in between, your program will not run, or at least not achieve the desired effect. It is completely equivalent to a pile of code full of bug in terms of utility. You may argue that the program is not finished yet, but the function has not been implemented yet, and there is no bug. In fact, for the sake of others, the absence of a function and the inclusion of a malfunctioning function are useless to the user. An unfinished code in the development phase is the same thing as a defective code at the end of development.

This leads to a famous proposition:

That's not a bug, it's a feature request.

Sometimes it's hard to tell whether a problem belongs to bug or feature request. In this paper, the author gives a case: when building a Windows GUI program with Visual Studio, the system does not use the default font. Does this count as a bug?

I don't know. After all, with the increasing popularity of software applications and the pursuit of the so-called humanization trend, the traditional view that as long as the program can run is not bug, is also slowly changing. For a compulsive cancer user, there is a defect in UI, so the whole software basically doesn't work. In fact, in today's era of fierce competition and homogenization of all kinds of app, the problems in user experience are often fatal. In the past, people didn't have a choice, so they were not so picky, as long as the program worked. Today's computer users have been spoiled, in this era, bug has been quietly generalized.

So, how on earth can you write code without bug?

Answer: don't write code.

The only solution that is pessimistic and desperate but correct.

Try to dig some hope in this despair. This answer implies a methodology: write as little code as possible. Because Master Dijkstra has made it very clear that programming is the process of making bug. Then, it is obvious that the less code is written, the less likely it is to make mistakes. It's easy to be confident to maintain a code of 300 lines; to take over a code of 3000 lines, the reaction depends on the quality of each person.

Modern development methods also include this idea, from IDE's smart tips and code completion features to various "21-day beginner to proficiency" development frameworks that every language has, as well as many practical conventions that help developers reduce unnecessary coding. Framed and standardized thinking can reduce the possibility of making mistakes.

In fact, even the historical development of the programming language itself is based on this line of thinking. From the low-level assembly language, to the Cumberbatch, to the Java/C#/Python. One of the purposes of language evolution is to liberate programmers from dirty and hard work.

On the one hand, the spirit of "do not repeat wheels" is to guide us to improve efficiency and not to repeat labor costs, on the other hand, it is also to reduce the chances of repeated mistakes.

Various concepts of package management in contemporary Web development are profoundly practicing this spirit, so that the famous NPM & left-pad event broke out in March 2016: a string filling function module with only 11 lines was relied upon by the whole world. As a result, the global front end crashed on the day that the author Azer removed the module package. Affected products and teams even include the famous React!

This event makes people start to think: have we forgotten how to program? A function is so simple that everyone can write a function, but they all choose to introduce it rather than implement it themselves. In the end, it's not as good as going too far.

It's really hard to write code.

However, if you really have no choice but to write code, then programmers who already have no girlfriends now don't even have code, which makes people live or not?

Programmers can not be forced to death like this, we should talk about human rights.

Sometimes, when the answer is really unacceptable, we should think about whether we are asking the wrong question.

So, to put it another way, why pursue no bug? Maybe we don't have to be afraid of bug at all.

Where there is bug, there is trouble, where there is trouble, there is a need to solve problems, and customers pay those who can solve problems. It is worthless to deal with simple problems, and the market only recognizes those who can provide solutions in the face of difficulties. To put it simply, if you want to make money, don't be afraid of trouble.

For customers, whether bug or feature request, it is a problem that needs to be solved. An excellent PM can package the bug of customer feedback as feature request and return a set of solutions. Then, excellent business representatives come forward to sign supplementary agreements. Congratulations, your project funding has increased a little bit.

The above is how to write code without BUG. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.