How to do code Review effectively

How to do code Review effectively
what is code Review.

Code review Codes review refers to the process of systematic checking of source code during software development. The general purpose is to find a variety of defects, including code defects, functional implementation problems, coding rationality, performance optimization, etc., to ensure the overall quality of the software and improve the developer's own level. Code review is lightweight, and the cost of a lightweight code review is significantly lower than a formal code review, and it can be more positive if the process is correct. Because of this, lightweight code reviews are frequently introduced into the software development process. why code Review.

1. Improve code quality.

2. Identify potential defects early and reduce the cost of modifying/remedying defects.

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

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

5. Is a means of passing knowledge that allows others unfamiliar with the code to know the author's intentions and ideas so that the code can be easily maintained later.

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

7. Can be used to confirm that their design and implementation is a clear and simple. How to do code Review. Code Review check what.

1. Structural issues

The biggest problem with the code is not that there are technical flaws in one or two places, nor business logic errors, but the poor design of the whole software. The first two are easier to detect and correct by testing or using, but the latter is different. If you think about the various kinds of mess that you have seen, do you agree. Specific where there is a problem how to change to say, is the whole software seems to be confused without a chapter, do not know.

Specific structural problems include: Duplicate copy code (not encapsulated function, no template/generics ...) ), the function is too long (more than one screen is called too long), error encapsulation (improper public/without interface//strong coupling/encapsulation of unrelated methods in the class ...) ), content error (multiple unrelated classes placed in a file/inappropriate naming ...) And so on

Correcting structural problems is an important way to develop reliable software and to write beautiful software.

2. Business logic Issues

Is the question of whether the software meets the requirements. The reviewer and the reviewer often have different understandings of the business requirements, taking this opportunity to synchronize and, if necessary, to introduce the PO (Product Manager/Product owner).

Some would say that the business logic problem is not a test. However, the test generally occurs after a long time, some logic tests also need a certain trigger conditions, and the test will only find the failure (failure, and expectations do not match) and can not find defects (defect, specific where out of the wrong), and so accumulated long, who can not find the reason.

3. Programming Literacy Issues

A lot of the problems are the kind of "It's OK", like named/init/indent/Line break ... But the best practice is always better than the novice.

such as bool result= true; This sentence has a problem, just the initial declaration of success, there will be hidden trouble. This is a real case, and there is indeed a branch that incorrectly returns this true (the actual case is an HRESULT). The problem is not testing but code checking. In fact, the test can hardly find these problems, such as the above code will be wrong when a file is not open to return this true, and in the test almost no story destroys that file to test its results. Regular Code Review

The common code review is a novice reviewer, or the master walks The Apprentice. Generally speaking, the master can write more than 100 lines of valid code per day (by semicolons), the novice will be more but not more than 200 (they write code comparison fee), that is, 10 of the screen. Experienced people must know: Master look at the novice code, 5 seconds to find the problem. So instead of spending a lot of time doing code Review, you should "eat less," 5 minutes, 10 minutes, 2-3 times a day, or more. See a problem to be completely solved, do not need to check a lot, the problem is less than once.

But remember not to accumulate, after a long time to do code Review, you will face that near the line of code, before n more mixed function, you will find that the entire code Review become very difficult, not a moment, you will find that you will be tired of yawning, but still insist, Sometimes, such review will last more than n hours, rather exaggerated. And there will be quite a lot of problems and arguments, because, this is like, people have to cover the whole house, we review when this pick a little bit, sometimes touch the foundation or load-bearing wall, need a large operation, let people rework, which of course will let the people of the house jumped up to jump up vigorously to maintain their code, And finally hurt the feelings of others. How do we do Code Review

I have taken the project, do codereview this aspect mostly feel more messy, there is no unified approach. However, from the formal point of view can be divided into two broad categories: one is the TM technical manager of the project members of the team to do a code Review, or a team of senior staff to do (call it personal). One is to do code Review meeting, in the form of a conference to do code Review (call conference style).

1. Personal type

For personal, in fact, "How to do Codereview" in the above topic has been talked about a lot. We have to do code Review in a timely and irregular manner, including the problem of structure, business logic, programming literacy, and so on. We've done a lot of projects, and we've even done it. But there is not good enough place, need to go deep in the place. The specific method above has been said, I will explain in detail how to quantify and follow. For PM, how to monitor code review is very important.

2. Conference Style

Conference style, real conference style to do code review, if done in place the effect should be the best, the ideal situation is a bunch of experts (including technical experts and even business experts, test experts, etc.), take the code line to review. But the cost of this approach is also very high, whether it is time cost or cost is quite expensive, generally only in large-scale cutting-edge projects will be used, such as aerospace projects, code review after the defect rate is quite low. What do we do with code Review meeting? First of all, we will choose a typical case or issue to be discussed together before the meeting, most of which is to share some experience and highlight some of the easy mistakes. Usually one meeting will not exceed 2 hours, once a week meeting. The results of this meeting are better and the costs are relatively low. Because of the uneven quality of the members of the team, it is really bad to do a code review together. I think a little bit about Code review.

As PM me, thinking about code Review is how I should manage code Review. That is to say I think of code review as a project, how to do this project.

In fact, it is very simple, first I want to have a correct, real, executable plan, and then in the implementation of code review to give TM or reviewer a certain guidance, and then tracking deviations, analysis of reasons, change plans.

So how do you plan. And if it's right, true, and executable. Here we need to combine project quality plan. There may be children's shoes do not know, I briefly explain the project quality Plan,project Quality plan is a program quality program, the main content of the project deliverables and delivery requirements, plan to achieve the quality objectives, how to take the process method, Quality breakdown the quality target decomposition in each stage and so on. By decomposing the detailed quality targets, we can predict how many defects are expected to occur at each stage. At this time we have to think about the PM, with the number of defects in each stage, we can not decompose, then we do code review goal is to find how many defects. For example: Assuming that our code size is 100k, we currently have a baseline of the number of defects in the team is 12~15 (bugs/kloc), code review need to find 8~10 (Bugs/kloc), that is, 100*8~10=800~1000. In this way we have the total, that is, for the 100k code line of this size of the project we codereview to find a total of 800~1000 defects in order to achieve a better effect. Of course, if this is not enough, we also need to refine the decomposition of this goal. To decompose into a module, decompose to a person (if more than one review). Decomposition to the module well understood, we break down the whole system into several large modules, or sets of modules (the correlation can be put together). Then analyze the difficulty of the module, as well as the possible future owner of the module, and then evaluate how many defects we should find for each type of module. It may take more time to review and produce more defects than a module with complex or complex algorithms or a lower level of owner, but less. The following figure:

Module	Scale	Complexity of	Pic	Defect distribution	Calculation	(Adjustment factor)
1	20k	High	In	240~288	20*12	1.2
2	20k	In	In	180	20*9	1
3	20k	In	In	180	20*9	1
4	20k	In	Weak	180~198	20*9	1.1
5	20k	Low	Weak	120	20*6	1

With the concrete plan Codereview also has the guidance and the reference target. In the implementation of the time we can also plan for people to allocate a reasonable force. It is comparatively easy to do.

The last is tracking, deviation analysis and change, when we find that we have serious deviations from the actual plan we have to analyze the reasons, and then make plans to change. For example, when we find deviations, we can use root cause analysis, human, machine, material, method, ring, test. Where we do not good enough, if we can solve, find out the main reason to solve immediately. If you find that the plan has a problem, change the plan. There is no concrete way to discuss this. There are many ways to do this, as long as you are suitable for your project.

In fact, there are many methods of codereview, such as pairing programming is also a good form, especially for Agile XP team, but because at present I do not have good practice, so also did not write.

Finally, I hope I can write a little help to everyone. Also welcome to code review have their own views of friends can join me to explore this topic. And welcome to correct me in the wrong place. Thanks

Another: The text is part of the content from the Chen Yong Teacher's blog, thank you very much here. Please understand the teacher, I quote come.