On the importance of code walking and checking

In a team, if there is no code review, directly allowing development to submit code to the repository and deploy the environment, then before the formal start of testing the code is very necessary to check.

Here's what we're talking about. Instead of using tools to check code specifications before continuing integration, verify that the implementation of the code conforms to the requirements description, based on the PRD documentation.

Before starting the test, I would synchronize the development of the code, and then ask the developer specifically what interfaces involved in this feature, and then starting from each interface, look at the business logic Layer and database access layer code to see if its implementation is consistent with the requirements, and identify some obvious errors. The only way to do this is to save time. In fact, these issues should be discovered by code review before the development of the submission code, but because the team has just been formed, there is not a reasonable set of processes and time is very limited. In fact, these malignant bugs can be found in the testing phase, but also in the smoke test stage can be easily found, but the problem is still time tight, it is better to go through the code, the wrong place and the development of communication, after the bug, the specific row which location of the problem marked, so that can greatly accelerate the test progress, At least you can quickly make the test pass the smoke phase, saving some time.

Here are a few chestnuts to illustrate some of the obvious issues I found during the walk-through phase:

　　

First look at this code:

　　

When the database read the query is the unsettled type of bill, but the query results are directly assigned to a reference named Settledbills, OK, then the code is wrong.

Give me another chestnut:

　　

This calls the Dubbo service interface, docking another system, the incoming enumeration Unsettle_bill_repay, representing the meaning of reimbursing the unpaid bills, but this code is used to repay the billing service layer code ...

In fact, this problem in our project code found a lot of, in the two systems docking, the two-party developers almost do not communicate, see which interface like directly called, and then all pushed to test to measure, found that the problem and then change, found not to hehe, do not say, are tears ...

Summing up, in the face of unreliable, non-communication development, almost no management of the project, all by testing manually found the problem is the Pear Mountain big AH.

On the importance of code walking and checking