How to Improve Code Quality (Management): Code Review

Maybe you are a project manager, maybe you are a key project member, or a development team leader. After I published the systematic article "How to Improve
Code , many netizens complained to me that they could not grasp the code quality of the entire project team members. I think this is also a common problem for all project teams. It
usually manifests as the following problems: Common problems

in software projects

1) Novices. Newbies are inevitable with any project team member, often fresh out of college. Because the software development time is too
short , the technology is often immature and good development habits have not been formed, so the quality of the code written is poor and there are many problems. They often become the “chicken ribs” of the project team. If they use too much, the quality
of the project cannot be guaranteed.

2) Staff changes. For a software project with a slightly longer maintenance time, personnel changes are inevitable. Older employees were moved to other projects, and new
employees took over their jobs. In my project team, the personnel transfer reached 90%, and the only person who did not transfer was myself. When new employees replace old employees for code
maintenance , or even continue new development, there will be a lot of inferior code due to the deviation of understanding of the original code and design ideas.

3) Irregular code writing. Even if the influence of the above two problems is removed, the code written by the project team members will also have problems. At the beginning of project development,
we often formulate a code writing specification, but in the process of project development, many members tend to ignore these code specifications and write at will.
Writing code haphazardly reduces code readability, maintainability, and changeability. Then, what kind of management measures should we adopt to ensure the standardization of the code and improve the quality of the
code ?
The above problems are also the problems that I continue to explore and think about in the project development, and some experienced project managers have given their solutions, that is, "replacing
"Code Review".

What is

Code Review? Code Review, also known as "Code Review", the basic idea is that after the developer has written his own code, other people will review
the code he wrote, so as to effectively Find defects in the code. A basic theory of code review is that the earlier we find
defects the lower the cost of fixing them. Code reviews are often divided into the following aspects:

1) Code style. In At the beginning of project development, we often formulate a code writing specification. In fact, this code specification includes the
code . Due to the different design habits of software developers, if the code style is not unified, the The code will be various, such as the naming of variables and constants,
the annotation of interfaces and implementation classes, when to enter, how to indent, etc. A variety of design styles will inevitably bring difficulties to future maintenance and improvement. We pass the code
Code review, on the one hand, urges developers to write code in accordance with the specifications, and on the other hand enables developers to form good programming habits themselves. Code style review, due to
the relatively simple content, can often be done automatically by some code review tools 2) Major defects. In some articles on code review

, a common list is listed, describing the major defects that should be paid attention
to including: SQL injection, vulnerability to cross-checking Site scripting attacks, buffer overflows, managed code, etc. The project team can continuously accumulate review projects for major defects and check them one by one in
each review. Major defect review is a tedious and detailed work, if you can write or use some Reviewing software can greatly improve our review
efficiency .

3) Review of design logic and ideas. I think this part of the review is the core and most valuable part of code review. Review of code style and major defects
Although it is important, it is simple and mechanical, and can be automatically checked by software; while the review of design logic and ideas is a complex and in-depth review, which requires people with a certain theoretical
depth and coding experience to complete it, and is especially important for novices. . As mentioned earlier, novice is an inevitable problem for any project team. Unfortunately, the approach of many project
managers is to leave only a few simple and small tasks to the novice, and a large number of complex tasks to be done by a small number of veterans. As a
result , novices are always novices, and they don't get enough training; veterans are exhausted and can't expect novices to share the work. For this problem, my approach is
to let veterans guide newbies through code review, so that the overall quality of the team can be improved. The specific method is that after the novice completes the coding, let the old hand
review the , point out the problems of the novice, and guide the novice to design. Such a process may initially require refactoring, or even recoding. But after such a process, the novice will gradually become proficient and
quickly become a veteran, so that the overall quality of the team will be improved.

Forms and advantages and disadvantages of code review

After the above description, we can find that the advantages of code review are obvious. First of all, by reviewing the code style and specification, the
readability . Today's software often requires continuous maintenance and upgrades, and personnel changes are inevitable. Therefore, code readability and maintainability
are . Code review is a spur, because its existence urges developers to consciously standardize coding, develop good coding habits, and improve code quality. A problem worth
noting is that if you don't read other people's code, you will never be able to deeply understand what readable code is, and your own code will not be read and fed back by others, and you will never
know whether your code is readable or not. , even if you're a coding veteran for years. Code review solves exactly this problem and is worth trying.
Second, a code review is an exchange between programmers. Novices can have more opportunities to learn and guide from veterans and improve their design level (it should be said that this is very valuable
to them); veterans can organize and sublimate their design ideas and theories through guidance to newbies, and also Exercise and improve yourself on
the . In addition, when you find and point out a problem of others, you are also warning yourself not to make the same mistake, which is beneficial to both the reviewer and
the .
Although code review has such outstanding advantages, its disadvantage is also very significant, that is, it needs to pay such a huge price. When one person completes the
coding , another person is required to interpret and review, and the programmer is required to complete the corresponding modification, or even refactoring and rewriting, which itself is a huge cost.
This is undoubtedly aggravating for a software development project that is already very tight in terms of personnel and time. Time, manpower, and code quality are inherently
incompatible . The key is how to balance them. Because of this, different companies choose different code review strategies.
Not long ago, I listened to a major Korean game software company talk about their code review. Since this company is developing software, time and manpower are not the most critical and
urgent issues but code quality, so they adopt a strict code review strategy. Strict code review strategy, one way is to have code review by a dedicated person.
In this way, in the form of personnel organization, some experienced people are individually selected from the software developers to form a code review team, which is dedicated to reviewing the code of other software
development teams. In this way, the code review team reviews the code of each project team as a third party, which can ensure the fairness and impartiality of the review, but the pressure
is undoubtedly huge (think about how much code they have to review).
Another way is to use a project development team as a unit to conduct code mutual inspection, that is, one person's code should be reviewed for all members of the team. There is
no is too costly. A workaround to this approach is to combine pair programming in XP, and then the two people in pair programming check each other's
code . Project teams that use pair programming can try this method. Unfortunately, there are too few project teams using pair programming in China.
The biggest drawback of the above two code reviews is the accountability system, that is, the reviewer does not have much responsibility to discover the problems of the reviewer, and the problem is not beneficial to the reviewer, but complains with
the reviewee; on the contrary, the review The operator does not find the problem and will not take any responsibility. The result is that code review is a mere formality: reviewers scribble, everyone is
happy , and problems persist.
To sum up, although the advantages of code review are obvious, the above forms are not acceptable to ordinary software development teams, so I offer my best
practice : code with team as unit and team leader responsibility system Review form.

Best Practices for Code Reviews

Code reviews come at a cost, sometimes huge, so code reviews shouldn't be frequent, preferably only once for a piece of code. At the same time, the code reviewer should
be responsible for the code reviewed, that is, be able to boldly review and point out the problems of the reviewer, and require the reviewee to rectify within a time limit. At the same time, the reviewer should be held responsible
if . Only if the above three conditions are met, the code review can be accepted by us. Undoubtedly, the
leader be most appropriate to take on this responsibility.
A project development group can be divided into multiple groups according to the division of its functions, and each group is responsible for a sub-module. In such a group, the group leader has no
Suspect is the most experienced developer, and it is appropriate for him to be responsible for organizing and directing the other members. The group members should not be too many, usually 3 to 5 people. The team leader should not assign too
many development tasks. His main job is to guide and supervise the development of other members of the team. Freeing him from heavy development tasks, he can focus more
on directing other members' designs and reviewing their code. Ultimately, he is responsible for the code quality of all members of the team, and the project manager or quality manager conducts
spot checks to check the overall situation.
If you're just a small project with less than 5 people in total, then you don't need to group like this. You, the project manager, are that team leader, directing and
supervising your members. This arrangement is because in modern management theory, one person can only manage 5 people at most, and more than 5 people should be managed in groups. And if you
are within 5 people, of course you don't need to separate.
As a team leader, you can effectively review and manage your team members. At the same time, because of your responsibilities, you also have to do the review work seriously and efficiently.
Through the above organizational forms, code review can be easily and effectively carried out in the project team, thereby effectively improving the code quality of software development from management.


From: http://fangang.iteye.com