How to reduce bugs in development

This article comes from the public number: Front-end bottle king author: jartto

First, an overview

Einstein once said, "If you give me an hour to answer a question that determines my life and death, I'll take 55 minutes to figure out what this question is asking." O nce you know what it's asking, the remaining five minutes are enough to answer the question. 」

Although our software development process will not face the choice of life and death, but it directly affects the user's feelings of use, determines the direction of the product. So how programmers reduce bugs in development reflects both code quality and individual comprehensive capabilities.

So how can we effectively reduce bugs in development?

I think there are two things I should start with: the business layer and the code layer.

Second, the business level

Let's not go into details about the software development process and look directly at the most important nodes:

1. Demand discussion stage Must be clear requirements, testing, development, product three parties must agree. If there are no clear problems in the early stages, the latter stages can result in ineffective rework and unnecessary disputes, which are especially common in day-to-day development.

Therefore, in the early stages of software development, we will conduct three stages of "review, counter-assessment, evaluation".

2. Development completion phase Once the development is complete, the programmer must first complete the "self-test", that is, the "smoke test" in software development, to ensure that the main process is correct. Otherwise, after the development engineer submits the code, the test engineer is struggling to carry out the test effectively, resulting in a great waste of resources.

A more standardized process requires the test engineer to write a "test case" after the requirements are clear, and the development engineer completes the initial validation against the "test case" after completion of the development, after which the code can be tested.

The benefit of this is that it ensures "high-quality code delivery" while reducing the workload of test engineers.

3. What's the difference between self-test and test, from the software development process, in fact, development engineers and test engineers actually completed different stages of testing:

Development engineer "white box test": refers to the actual operation of the program under test, through the source code of the program for testing without using the user interface. This type of test needs to correct the shortcomings or errors of the internal code in terms of algorithms, overflows, paths, and conditions from the code syntax.

White box testing needs to correct the shortcomings or errors of internal code in algorithms, overflows, paths, conditions, and so on from code syntax.

The test engineer actually performed a "black box test". S o what is a "black box test"? B lack box testing, also known as functional testing, is a test that detects whether each function is working properly. In testing, the program is treated as a black box that cannot be opened and tested on the program interface without regard to the internal structure and characteristics of the program at all.

It only checks whether the program function is working as required by the requirements specification, and whether the program can properly receive the input data to produce the correct output information. Black box testing focuses on the external structure of the program, regardless of the internal logical structure, mainly for the software interface and software functions to test.

The black box test is tested from the user's point of view, from the correspondence between the input data and the output data.

Obviously, if there is a problem with the design of the external feature itself or if the specifications are incorrect, the black box test method cannot be found. The black box test method focuses on the functional requirements of testing software, mainly trying to find the following types of errors.

功能不正确或遗漏；界面错误；输入和输出错误；数据库访问错误；性能错误；初始化和终止错误等；

Third, the code layer

At the code level, we need to start with the following:

1. Eslint avoids low-level syntax problems This is obvious, the writing process found problems, avoid because of simple syntax, such as: missing commas, variable name miswriting, case problems

2. Boundary processing Do a good job of fault tolerance, the necessary emptying, there is the code boundary problem. T hink more about what we would do if the array didn't exist. I f the array crosses the line, how do we fix it? If data is missing, how do we keep the page from crashing?

3. Unit tests If time permits, we can do unit tests, compile the code each time, or start the script before the test to make sure that the test script covers the core code, minimizing the rate of code errors.

4. Accumulation Why to accumulate, in fact, the reason is very simple. A s your development experience grows, you may encounter many problems, so if you accumulate carefully, many mistakes are unknowingly handled. O n the contrary, you will continue to fall into the same pit, in the pit and out of the pit to lose themselves. So how do we accumulate?

First of all, encounter their own problems, if the first time did not solve, by finding or consulting others to solve, then be sure to use a small book to write down, the best use of cloud notes. The benefits speak for themselves.

Secondly, to accumulate their own library of functions, we often use some methods, may as well do their own encapsulation, and constantly precipitate. Maybe one day you'll find yourself unknowingly writing out a Lodash library.

Finally, you can accumulate good code snippets, well, "We don't produce code, we just good code porters."

5. Learn a word, there is nothing more interesting than learning excellent open source code. Read excellent source code, learn the author's ideas, stand on the shoulders of giants, you can go further!

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

Fourth, summary

For those who are benevolent to such open issues, wise people to see wisdom, I believe that everyone will have their own views, but also have their own unique approach. W hether it's a black cat or a white cat, it's a good cat that can catch a mouse. For programmers, the way to reduce bugs is a good one.

Here's a description of W3Cschool编程狮 can reduce bugs in development, and hopefully it's helpful.

There is a saying among the group of programmers: there are no bugs without writing code.

We can not be afraid of making mistakes and reduce the writing of code, but also should know the difficulties, the more frustrated the more brave. Be aware that "bugs are inevitable and can only be reduced" in everyday development.

Of course, this shouldn't be a reason for us to write bugs. Constantly beyond, the square is eternal.