An overview of the

Recently, I participated in the development of several requirements, but there were few bugs. Some requirements had no bugs, and some had only one BUG. The testers complained,

Big guy, you are in charge of the project, the bug is little pitiful, call me how to live?

Haha, the testers have me to thank, because the quality of the developers’ code will greatly improve the speed of the testers, because the testing process is very smooth, there is nothing in the way. Imagine, if after the test, the code BUG, the testers constantly BUG list, developers of repair, carelessly may fix the BUG to other, intersperses among various unnecessary discussion, these have seriously affected the testing progress, of course, seriously affect the mood of the testers and developers. Therefore:

It’s best to get down to business in the development phase and get the code right so that the rest of the process runs smoothly.

So how do you avoid bugs when you write code? Take this opportunity to share with you what I do.

Try to avoid bugs

Communicate with product managers and experienced testers

The requirements phase

Before the formal requirements meeting, the product manager will send out the requirements document first. At this time, the developer must carefully look and analyze, think about every detail, and communicate with the product manager in time if there is any doubt. In addition, when looking at requirements, it is best to communicate with testers who are familiar with the business. Testers are the ones who have the best knowledge of past requirements and can see details that others cannot. I, for one, often hear fatal requirements details from testers that I have missed.

Code design stage

When I have a plan in mind, THE first thing I do is go to the technical boss and the testers who are familiar with the business. Can accomplish technology eldest brother, his train of thought is more broad generally, listen to his opinion more is right. Also, go to the testers. Some developers may think, how can technical solutions be discussed with testers? Please do not forget that some testers are familiar with most of the applications, requirements and business of the entire company, and can clearly understand how systems interact with each other, how the whole link goes, and what the whole context is like. When the developer’s design scheme comes out, it looks perfect on the surface, but in fact there may be hidden dangers affecting the upstream and downstream systems. By communicating with testers who are familiar with the business, these problems can be exposed early and the impact and loss can be reduced.

Code development phase

Unit tests must be written

The importance of unit testing cannot be overemphasized. It’s a great way to test your code to see if it works as expected. Especially in startups, there are a lot of requirements, often need to change the code, if you don’t have a complete set of unit tests to verify the code regression, the original code function will be broken due to new code. Unit testing allows developers to make bold changes to the code without worrying about affecting previous functionality.

But unit tests must be written responsibly and try to cover the main process business. The kind of unit tests that you write and verify are pointless and a waste of time.

Look at your code over and over again

Before the code is tested, you should look at it several times, sometimes you can see some hidden code bugs, sometimes you will feel that the code written yesterday is really garbage, or there is a lot of code to optimize.

While looking at the code, it’s a good idea to do the following:

  • Code collection is stronger, do not exist that kind of similar code flying around, can be encapsulated on the package;
  • Business code must be annotated exactly as necessary, and don’t fall for the myth that a set of method names will explain everything;
  • Variable names should be well chosen;
  • The code abstraction level should be consistent and not jump, for example, when your business methods operate on other modules’ business tables, they are calledServiceClass, don’t pop up and use it directlyxxxxxMapperSQL > alter database table;
  • The flow is strong, it is best to use //1, //2, //3, so that it will be more clear.

We have to do a joint development survey

When your business interface development is complete, be sure to do liaison between developers. Joint investigation is end-to-end, and even if one side does a good job, there will be problems without joint investigation.

After passing the development joint adjustment, it is suggested to call the product for acceptance in advance

Generally speaking, after passing the functional test, the product will be accepted before going online. But I like to pull in the product manager after the joint development, and check it out. Do not underestimate this step, often can find some problems in advance.

Tester Test phase – See log

Do not think that after the test, there is nothing to do, it is best to take a little time to test the machine to see the log, observe and analyze the input and output parameters, see if there is any abnormal or unreasonable data.