How can programmers reduce bugs in development?

At the weekly meeting, my colleagues raised a question , How can programmers reduce the number of Bug? A very interesting topic , In this article, we will discuss and summarize .

One 、 summary

Einstein once said ：「 If you give me an hour to answer a question that determines my life and death , I can spend 55 Minutes to find out what the question is asking . Once you know what it's asking , The rest 5 Minutes is enough to answer this question .」

Although our software development process will not face the choice of life and death , But it has a direct impact on the user's experience , Determines the direction of the product . So how can programmers reduce the number of Bug, Both reflect the code quality , It also reflects the individual's comprehensive ability .

So how can we effectively reduce the Bug Well ?

I think we should start from two aspects ： Business layer and code layer .

Two 、 The business layer

We won't go into details about the software development process , Let's take a look at the most important nodes ：

1. Requirements discussion stage

Be sure to clarify your needs , test , Development , The three parties of the product must reach an agreement . If there are no clear problems in the early stage , Then later it will cause invalid rework and unnecessary disputes , This is particularly common in daily development .

therefore , Early stage of software development , We'll all do 「 review , Converse , assessment 」 Three stages .

2. Development completion stage

After development , The programmer must first complete 「 Self testing 」, That is, in software development 「 Smoke testing 」, Make sure the main flow is correct . otherwise , After the development engineer submits the code , Test engineers are struggling , The test cannot be carried out effectively , It will cause a great waste of resources .

A more standardized process requires the test engineer to write after the requirements are clear 「 The test case 」, After the development engineer completes the development , Self control 「 The test case 」 Complete preliminary verification , After that, you can test the code .

The advantage of this is that it ensures 「 High quality code delivery 」, At the same time, it reduces the workload of test engineers , Why not ?

3. To measure

What is the difference between self-test and self-test , From the perspective of software development process , In fact, the development engineer and the test engineer have actually completed different stages of testing ：

Development Engineer 「 White box testing 」：

• It refers to the actual operation of the program under test , Test through the source code of the program without using the user interface . This type of test needs to find the internal code in the algorithm from the code syntax 、 overflow 、 A defect or error in the path or condition , Then correct it .

The white box test needs to find the internal code in the algorithm from the code syntax , overflow , route , A defect or mistake in a condition, etc , Then correct it .

What the test engineer actually does is 「 Black box testing 」. So what is 「 Black box testing 」 Well ?

Black box testing is also called functional testing , It's a test to see if every function works properly . In the test , Think of the program as a black box that can't be opened , Without regard to the internal structure and characteristics of the program , Test at the program interface .

It only checks whether the program function is in accordance with the requirements specification , Whether the program can properly receive input data and produce the correct output information . Black box testing focuses on the external structure of the program , Without considering the internal logical structure , Mainly test the software interface and software function .

Black box testing is from the user's point of view , Starting from the corresponding relationship between input data and output data .

Obviously , If there is something wrong with the design of the external features or the specification is wrong , You can't find it with the black box test . Black box testing focuses on the functional requirements of testing software , Mainly trying to find the following types of errors .

• Incorrect or missing function ;
• Interface error ;
• Input and output errors ;
• Database access error ;
• Performance error ;
• Initialization and termination errors, etc ;

3、 ... and 、 Code layer

The code level , We need to start from the following aspects ：

1.Eslint Avoid low-level grammar problems

That's obvious , Problems found during code writing , Avoid simple grammar , Such as ： Missing comma , Wrong variable name , Case problems, etc

2. Boundary treatment

Fault tolerance , Necessary air judgment , There is also the code boundary problem . Think again if the array doesn't exist , How do we deal with ? If the array is out of bounds , How do we fix ? If the data is missing , How do we keep the page from crashing ?

3. unit testing

If time permits , We can do unit tests , Every time you compile code , Or start the script before the test , Make sure that the test scripts cover the core code , Minimize code error rates .

4. The accumulation of

Why should we accumulate , In fact, it's very simple . As development experience grows , You may encounter many problems , So if you accumulate carefully , In fact, many mistakes are dealt with unconsciously . conversely , You will keep falling into the same pit , Lost in the pit and out of the pit . So how do we accumulate ?

• First , When you encounter problems you won't be able to solve , If it is not solved at the first time , By looking for or consulting others to solve , Then you must write it down in a small notebook , It's best to use cloud notes . The benefits are self-evident .
• secondly , Accumulate your own function library , Some of the methods we often use , You might as well make a package by yourself , Keep settling . Maybe one day , You'll find that , I wrote a story without knowing it Lodash function library .
• Last , You can accumulate excellent code snippets , Um. ,「 We don't produce code , Just good code movers 」.

5. Study

In a word , There is nothing more interesting than learning good open source code . Read excellent source code , Learn from the author's thoughts , Standing on the shoulders of giants , You can go further !

Do the above , I believe you will be an excellent engineer .

Four 、 summary

Different people have different opinions on such open issues , Wise men see wisdom. , I believe everyone will have their own views , It will also have its own set of unique methods . It doesn't matter whether the cat is black or white , A good cat catches a mouse . For programmers , Can reduce Bug A good way is a good way .

There is a popular saying among programmers ： If you don't write code, there will be Bug.

We can't write less code for fear of making mistakes , We should go up even more in the face of difficulties , The more frustrated, the braver . Know that in daily development 「Bug Is inevitable , Can only reduce 」.

Of course , This should not be what we write Bug Reasons for shirking . Constantly surpass , Square is eternal .

Copyright notice ：

The article was first published in Jartto's blog , Please be sure to indicate the source of the article in the form of hyperlinks , Author information and this copyright notice ( http://jartto.wang ).