At the weekly meeting, a colleague raised a question: how can programmers reduce bugs in development? A very interesting topic, this article we will discuss and summarize.
An overview,
Albert Einstein once said, “If I were given one hour to solve a question that would decide whether I should live or die, I would spend 55 minutes trying to figure out what the question is asking. Once I know what the question is, five minutes would be enough to solve it.”
Although our software development process will not face the choice of life and death, but it directly affects the user experience, determines the direction of the product. So how programmers reduce bugs in development reflects both code quality and individual comprehensive ability.
So how can we effectively reduce bugs in development?
I think I should start with two aspects: the business layer and the code layer.
Second, business layer
We won’t go into the details of the software development process, but will go straight to the most important nodes:
1. During the requirement discussion stage, it must be clear that requirements, testing, development and product must reach an agreement. A lack of clarity early on can lead to ineffective rework and unnecessary conflict later on, which is especially common in daily development.
Therefore, in the early stage of software development, we will carry out three stages of “review, conversely, evaluation”.
After development is complete, the first thing programmers need to do is “self-test”, or “smoke test” in software development, to ensure that the main process is correct. Otherwise, after the development engineer submits the code, the test engineer will struggle to conduct the test effectively, resulting in a huge waste of resources.
A more standardized process requires the test engineer to write “test cases” after the requirements are clear, and the development engineer to complete the preliminary verification against the “test cases” after the completion of development, and then the code can be tested.
The benefit of this is to ensure “high quality code delivery” while reducing the workload of test engineers, so why not?
3. What is the difference between self-testing and self-testing? From the perspective of software development process, development engineers and test engineers actually complete different stages of testing:
White-box testing: The practice of actually running the program under test, using the program’s source code instead of using the user interface. This type of testing involves identifying weaknesses or errors in the internal code in terms of algorithms, overflows, paths, and conditions from the code syntax and correcting them.
White-box testing involves finding flaws or errors in internal code from code syntax in algorithms, overflows, paths, conditions, and so on, and correcting them.
What the test engineer actually does is “black box testing.” So what is a “black box test”? Black box testing, also known as functional testing, tests each function to see if it works. In testing, the program is treated as a black box that cannot be opened and tested in the program interface without considering the internal structure and characteristics of the program.
It only checks whether the program function is properly used according to the requirements specification and whether the program can properly receive input data to produce correct output information. Black box testing focuses on the external structure of the program, not considering the internal logical structure, and mainly tests the software interface and software function.
Black box test is based on the user’s point of view, from the input data and output data corresponding relationship to test.
Obviously, if there is a problem with the design of the external feature itself or the specification is wrong, the black-box method will not be able to detect it. Black box testing focuses on testing the functional requirements of the software and attempts to detect the following types of errors.
- Incorrect or missing functions;
- Interface error;
- Input and output errors;
- Database access error;
- Performance error;
- Initialization and termination errors, etc.
See the article black Box Testing for more details
Third, code layer
At the code level, we need to start from the following aspects:
1.Eslint to avoid low-level syntax problems this is obvious, the process of writing code to find problems, to avoid simple syntax such as missing commas, variable names incorrectly written, case problems, etc
2. Boundary processing fault tolerance, necessary empty, and is the code boundary problem. Think about it a little bit. What do we do if the array doesn’t exist? If the array is out of bounds, how do we fix it? If the data is missing, how do we keep the page from crashing?
3. Unit test If time permits, we can do a good job of unit test, compile the code each time, or start the script before the test, make sure that the test script covers the core code, and reduce the code error rate as much as possible.
4. Accumulation Why say want to accumulate, actually reason is very simple. As you get more experience with development, you will encounter a lot of problems, and if you are careful, many of them will be handled before you know it. Instead, you keep falling into the same pit, losing yourself in and out of it. So how do we accumulate?
First of all, encounter their own problems, if the first time is not solved, through the search or consult others to solve, then be sure to use a small notebook, it is best to use cloud notes. The benefits speak for themselves.
Secondly, to accumulate their own function library, we often use some methods, might as well do a package, continuous precipitation. One day, you may find yourself writing a Lodash library without realizing it.
Finally, you can accumulate good snippets of code and say, “We don’t produce code, we’re just porters of good code.”
In a word, nothing is more fun than learning good open source code. Read excellent source code, learning the author thought, standing on the shoulders of giants, you can go further!
Do the above, I believe you will be an excellent engineer.
Four,
Different people have different opinions on this kind of open question, and I believe everyone will have their own opinions and their own unique approach. It doesn’t matter whether a cat is black or white, it’s a good cat that catches mice. For programmers, a way to reduce bugs is a good way.
There is a saying among programmers: no code, no bugs.
We shouldn’t write less code because we’re afraid of making mistakes. We should learn the hard way. Know that “bugs are inevitable and can only be reduced” in daily development.
Of course, this shouldn’t be a reason to write a Bug alibi. Constant transcendence is eternity.