How can programmers achieve zero code defects?

Programmers are either fixing bugs or on their way to finding bugs.

I think software work should be a high-intellectual activity that integrates technology and art. Our project manager should be a person who has a deep understanding of the objective laws of quality, scope and progress. "Efficient work, happy life" should be our motto.

But the reality is that the team is overloaded with requirements and fixing endless bugs. On the eve of the deadline, the project manager stared at us working overtime all night with red eyes, and the quality specialist urged us to collect quality data again and again, but it was still not enough. Software work has irreversibly fallen into manual labor. Let alone a happy life, life is gone.

Well, all of the above may be true. Project managers and quality specialists are big demons who don’t understand objective laws and have no sympathy. They make us programmers live in humiliation without dignity.

However, there is a sentence that has been held back for a long time: "Wake up, all of this is because your code is too bad and you have created too many bugs!" You may complain that this is clearly caused by too fast changes in requirements and too tight schedules by leaders. Well, it sounds reasonable, but you must know that changes in requirements are an objective law of software, and leaders require progress, haha, you can also think of it as an objective law.

This is not an argumentative article to prove who causes programmers to work too much overtime, nor does it want to give you chicken soup and make you become programming experts overnight, but at least it tells you some practical experiences and methods. In short, the more you read, the more practical value you will get.

***

Don't start writing code right away

You may be impatient, or you may have been eager to try out a little programming trick I just learned yesterday. What I want to tell you is, don't be impatient, put away your expression of sharpening your knife, there are more important things to do before you get the requirements and are ready to write your first line of code. I think it is not enough to emphasize the importance of this matter. In the experience of writing code that I am very satisfied with in the past, I have adopted this method, which can eliminate 90% of the bug tickets that may be raised by the test, and even achieve zero defects. Of course, it may take a process to achieve this.

After getting the requirements, you should first ask yourself whether you have fully understood the requirements. After getting a positive answer, we can start:

• 1) First, in your busy work, find an hour that you can fully control. This hour is completely yours. Make sure there will be no interruptions during this hour, or any interruptions that can affect your execution of this method. Remember that this hour is very important, more important than the time of all the activities you will perform later, and it is absolutely worth it.
• 2) Write "the normal process and impact scope of this requirement feature" on the top of the first piece of white paper, and then start writing down the contents of the normal process of this requirement feature one by one below the white paper, which library functions will be used, which interfaces will be provided, whether it will affect version upgrades, whether it will affect resource files, whether it will affect the original interface, etc.
• 3) Write down "all the abnormal scenarios of this requirement feature and some mistakes I often made in the past" at the top of the second piece of white paper, and then start writing one by one at the bottom of the white paper.
• 4) Repeat steps 2) and 3) continuously.

You may think that this is just like writing requirement clarification materials. I want to tell you that these are two different things. It is not a quality process activity that a quality specialist requires you to do. This is a deep conversation between you and yourself. You don't need to tell anyone or output any deliverables to other areas. This is a self-motivation to write excellent code.

You may find it difficult at first and stop writing after a few lines, or have a flash of thought: “Is this thing really useful?” Don’t worry, get up and go to the window to breathe some fresh air or get a glass of water. In short, don’t interrupt. Unless the office is on fire, don’t do anything that will prevent you from continuing.

When you slowly write down the 20th or 30th answer, you may suddenly feel a surge of emotion, "I have discovered such an obscure anomaly, it's amazing!" At this time, you will secretly exclaim that it is difficult to suppress your excitement, which means that you are close to success. Every answer you write will move you. Remember, don't give up in the middle. Your decision to persist will turn this hour into the most important hour in your entire demand realization.

second

Forget the damn quality activities behind it

All quality activities other than coding are based on the company's distrust of your coding skills. In other words, the company spends a lot of money to recruit quality specialists, network element testers, and solution testers, all because you didn't write the code well.

It is common to see some developers complaining about the quality activities arranged by the quality specialist when they first come to work, "I didn't need to do these things when I was doing projects in my previous company, and I was still able to complete the projects", "These quality activities are simply an invasion of coding time". It's all right to say these things, but when you say these things and bugs pop up after you finish writing the code, isn't it a bit shameless? These activities designed by the quality specialist are checkpoints designed to prevent your bad code from rushing to the customer. If you do nothing to "write good code" and only want to cancel these quality activities, it can only be understood as hooliganism.

So, can we "write good code" by doing quality activities well? The answer is no. Quality activities are only a means of supervision by quality specialists. They are neither a goal nor a method. The goal of writing code is not to meet the quality activity standards, but to pursue zero defects. You will not be able to write good code just because you do a good job in Wbit testing. One thing you need to do is "don't start writing code right away", and the other is to master as many refactoring methods and refactoring thinking methods as possible. Mastering refactoring does not necessarily mean refactoring the original code, but knowing how to write good code before writing.

I ask everyone to forget about quality activities, not to tell you not to listen to the quality specialist, but to have awe in your heart when writing code. All activities after the code is written are waste caused by you, and you must do your best to eliminate this waste.

third

Remember, you write code for people to see.

I once heard a colleague tell a very scary story about his previous company. A colleague of his former company resigned, leaving behind a pile of very complex C++ codes that would make people crazy. After he left, he found that no one in the entire project team could take over his module. The project manager had to pay a high price and treat him to dinner to come and explain his code to the entire project team for two days. This guy had a "homecoming" attitude of "see, only I can handle it". I am curious why the project manager did not fire him as soon as possible. He should have called the police.

Good code is pleasing to the eye. Any lack of ability or showy behavior that increases people's reading difficulties needs to be improved. Can you explain the context of the code you wrote in just a few sentences? Of course, this also involves mastering as many refactoring methods and refactoring thinking methods as possible.

Another criterion for self-evaluation is to ask yourself, "You have written so much code, have you ever been moved by it?" Do you read the code you wrote over and over again after writing it, and marvel at the beauty of the code?

As a programmer, I hope that among the several happy moments you recall after leaving the company one day, one will be the feeling of being touched by a piece of code that you just produced, rather than becoming the guy mentioned above who "the company only realized how important he was after he left."

fourth

Start practicing now.

Do you find yourself maintaining a coding level of "just enough to complete the story" for a long time, and still being chased by testers to issue bills after writing code for several years? All these doubts are because the improvement of coding ability has no direct relationship with how many years you have written code. What you need to do is deliberate practice.

For example, practice the methods mentioned in 01, 02, and 03 above repeatedly, or break down the methods you have figured out into steps, practice them deliberately, get feedback from the testers, and then continuously improve them. Slowly, you will change from a person who is chased by testers all day to a person who finds it easy to meet the quality process standards. Then, you will slowly find that it is becoming increasingly difficult for testers to find problems in the code you write. As long as you are in better condition, you can frequently write zero-defect code.

In fact, we all seem to know some truths, but I think there are still two steps to truly understand them. The first is that you need to experience and practice these truths and methods in person, and the second is that you need to be able to relay them so that others can understand them. So the best way to learn is to experience them in person, and then write them down and share them with others, so that you can truly understand those truths that you originally thought you understood but actually may not understand.

As I once saw a sentence: As a programmer, I hope to join a team that "spends 30% of the time writing code and 70% of the time drinking coffee and discussing how to make the product better."

I guess every programmer has such a vision, right? But first of all, as a programmer, have you done the four points mentioned above?