How to effectively perform code review

How to effectively perform code review

What is code review?

Code review code review refers to the process of systematically checking the source code during software development. The general purpose is to find various defects, including code defects, function implementation problems, encoding rationality, and performance optimization; to ensure the overall quality of the software and improve the developers' own level.
Code review is a lightweight code review. Compared with the formal code review, lightweight code review requires much lower costs. If the process is correct, it can play a more positive effect. For this reason, lightweight code reviews are often introduced into the software development process.

Why code review?

1. Improve code quality.

2. detect potential defects as soon as possible to reduce the cost of modifying/making up for the defects.

3. Promote knowledge sharing within the team and improve the overall team level.

4. The review process is also a restructuring process for reviewers. Help more people understand the system.

5. It is a means of transferring knowledge. It allows others who are not familiar with the code to understand the author's intentions and ideas, so that they can easily maintain the code in the future.

6. Encourage programmers to learn each other's strengths and advantages.

7. It can be used to confirm that your design and implementation are clear and simple.

How to Do code review? What does code review check?

1. Structure Problems

The biggest problem with the code is not the technical defect in one or two places, or the business logic error, but the poor design of the entire software. The first two are easier to detect and correct through testing or use, but the latter is different. If you think about all the mess you 've seen, do you feel the same way? Where is the problem? Why can't I change it? The whole software looks messy and cannot be started.

Specific structure problems include: copying code repeatedly (no function encapsulation, no template/generic ......), Function is too long (too long for a screen), error encapsulation (inappropriate public/no interface/no cohesion/strong coupling/encapsulated irrelevant methods in the class ......), Content error (multiple irrelevant classes are placed in one file/improper naming ......) And so on.

Correcting structural problems is an important way to move from writing reliable software to writing exquisite software.

2. Business logic problems

Is whether the software meets the requirements. The reviewer and the auditee often have different understandings of the business needs, and take this opportunity to synchronize and introduce Po (Product Manager/product manager) if necessary ).

Some people will say that the business logic problem is not just a test? However, a test usually takes a long time and some logic tests require certain trigger conditions. In addition, the test only finds failure (not as expected) and does not discover defects (defect, where is the problem?), no one can find the cause after the accumulation is long.

3. Programming literacy problems

A lot of problems come from the state of "doing the same thing as doing the same thing", such as naming/initial value/indentation/line breaking ...... However, the best practices are always better than new users.

For example, bool result = true; this statement has a problem. If it is just initialized, it will be declared successful first, and there will be hidden risks. This is a real case, and there is also a branch that returns this true by mistake (the actual case is an hresult ). This issue is not a test but a code check. In fact, the test can hardly find these problems. For example, the above Code will incorrectly return this true when a file cannot be opened, and in the test, it will hardly destroy the file to test the results.

Regular code review

The common code review is a beginner in expert review, or an apprentice in the master's case. Generally, experts can write more than 100 lines of valid Code per day (counted by semicolons). There will be more than 200 new users, but not more than (they are charged for writing code ), that is, within 10 screens. Experienced users must know that they can find problems in five seconds after reading the code of a novice. So it does not take a long time to do code
Review, instead of "eat less and eat more", each time can be 5 minutes, 10 minutes, 2-3 times a day or more. If you see a problem, you have to solve it completely. You don't need to check a lot at a time, but you can only check the problem at a time.

But remember not to accumulate. Code review will only be performed after a long time, and you will be faced with nearly lines of code. In the past, n many mixed functions, you will find that the entire code
Review becomes very difficult. In a short time, you will find that you may be tired and yawning, but you still need to stick to it. Sometimes, such a review will last for more than N hours, rather exaggerated. In addition, there will be a lot of problems and arguments, because it seems that people have built the entire house. When you review this, you can pick one point, sometimes it is necessary to operate on the foundation or load-bearing wall to make people rework. This will of course let the people who build the house jump up to maintain their own code, and finally hurt others' feelings.

How do we do code review?

In my projects, codereview is mostly messy and there is no uniform approach. However, the form can be roughly divided into two categories: one is that the TM technical manager performs code review on the team members in the project one by one, or the team senior personnel (just call it personal ). One is code review meeting, and code review (called meeting style) is made in the form of meeting ).

1. Personal

I have talked a lot about how to make a codereview in my personal style. This includes code review in a timely and irregular manner, including checking code one by one based on the structure, business logic, and programming literacy issues. We have done a lot of projects, even all of them. But there are still some areas that are not good enough to go deep. The specific method has been discussed above. I will talk about how to quantify and track it later. For PM, it is very important to monitor the code review.

2. Meeting Style

Meeting-style and real-time meeting-style code reviews should be the best if they are done, ideally, a bunch of experts (including technical experts and even business experts and test experts) Review the code one line by one. However, the cost of this approach is also very high, whether it is time cost or cost is quite expensive, generally used only in large and cutting-edge projects, such as aerospace projects, the defect rate after code review is quite low. How do we do code review meeting? First, we will select a typical case or problem before the meeting and discuss it together. Most of them share some experiences and emphasize some mistakes. Generally, a meeting will not take more than two hours. In this way, the meeting results are better and the cost is relatively low. Because the "quality" of the members in the team is uneven, it is really inefficient to perform code reviews together.

My thoughts on code review

As a PM, my thoughts on code review are: How should I manage code review? That is to say, if I use code review as a project, how can I do this project well?

In fact, it is very simple. First, I need to have a correct, real, and executable plan. Then I can give TM or reviewers some guidance when implementing code review, and then follow up on deviations, analyze the cause and change plan.

So how to make a project? And if it is correct, true, and executable. Here we need to combine the project quality plan. Some children's shoes may not be known yet. I will briefly explain the project quality plan. The project quality plan is a project quality plan with the main content including the project deliverables and delivery requirements, what kind of quality objectives are planned to be achieved, what kind of process methods should be taken, and the quality goal decomposition in each stage of quality breakdown. Through detailed decomposition of quality objectives, we can predict the number of expected defects in each stage. At this point, we need to think about the number of defects in each stage. Can we break down the defects?
The goal of review is to discover many defects? For example, if the size of our code is kb, the baseline of the number of defects produced by our team is about 12 ~ 15 (bugs/kloc), Code review needs to find 8 ~ 10 (bugs/kloc), that is, 100*8 ~ 10 = 800 ~ 1000. In this way, we have a total of 800-codereview for projects of K code lines ~ 1000 defects are considered to have achieved better results. Of course, this is far from enough. We need to break down this goal in detail. It should be decomposed into modules and people (if multiple people review ). Decomposition into modules is easy to understand. We break down the entire system into several major modules or modules (highly correlated modules can be put together ). Analyze the difficulty of the module and the potential owner of the module in the future, and then evaluate how many defects should be found in each module. We may need more time to review modules with complicated business or complex algorithms or low owner levels and to generate more defects, but less. For example:

Module	Scale	Complexity	PIC	Defect Distribution	(Computing)	(Adjustment coefficient)
1	20 K	High	Medium	240 ~ 288	20*12	1.2
2	20 K	Medium	Medium	180	20*9	1
3	20 K	Medium	Medium	180	20*9	1
4	20 K	Medium	Weak	180 ~ 198	20*9	1.1
5	20 K	Low	Weak	120	20*6	1

With a specific plan, codereview provides guidance and reference objectives. During execution, we can also plan reasonable manpower input and distribution. It is relatively easy to do.

The last step is tracking, Deviation Analysis and change. When we find that there is a serious deviation from the actual plan, we need to analyze the cause and then make a planned change. For example, we can use root cause analysis to identify deviations, such as people, machines, materials, methods, loops, and tests. If we can solve the problem, find out the main cause and solve it immediately. If you find that there is a problem with the plan, you should change the plan. The specific method is not discussed here. There are many methods, as long as it is suitable for your own projects.

In fact, there are still many codereview methods, such as Pair Programming is also a good form, especially suitable for agile XP team, but because I do not have good practice, so I did not write it.

Finally, I hope I can help you a little bit. You are also welcome to discuss this topic with me if you have your own opinions on code review. And you are welcome to correct me. Thanks

Another part of this article is from Mr Chen Yong's blog. Thank you very much. Please forgive me and I will quote it.