How to improve code quality (Management Chapter): Code review

Maybe you are a project manager, maybe you are a member of a project backbone, or a development team is long. After I published this system article "How to Improve code quality," many netizens complained to me that he was unable to grasp the code quality of the entire project team members. This, I think, is also a common problem for all project teams, and it usually manifests itself in the following questions:

Common problems in Software projects

1) Novice. It is inevitable that any team member will appear to be novices, who are often the only students who have just graduated from college. These novice because the software development time is too short, often the technology is immature, did not form the good development habit, therefore writes the code quality to be poor, the question is many. They often become the project team's "chicken Ribs", with a lot of project quality can not be guaranteed, but not enough manpower.

2) Personnel changes. A slightly longer maintenance software project, personnel changes are inevitable. The old employees were transferred to other projects and replaced by new employees. In my project team, the mobility reached 90%, and the only thing that didn't get transferred was myself. New employees in the replacement of the old staff for code maintenance, and even continue to develop new development, due to the original code and design ideas to understand the deviation, there will be a large number of poor code.

3 Code coding is not standard. Even if you remove the impact of the above two issues, the code written by the team members can also cause problems. At the beginning of the project development, we tend to develop a code coding specifications, but in the project development process, many members tend to ignore these code specifications for arbitrary writing. Random code writing can reduce code readability, maintainability, and ease of change. So, what kind of management measures should we adopt to guarantee the code and improve the quality of the code?

The above question, is also I in the project development unceasingly groping and the ponder question, but some experienced project manager has given their solution, that is "the Code review".

What is code review

Code Review, or "code review," is the basic idea of an effective discovery of the flaws in the code by someone else reviewing his code after the developer has written his or her own code. One of the basic theories of code review is that the sooner we discover the flaws in our code, the lower the cost of solving it. Code review is often divided into the following areas for review:

1) Code style. At the beginning of project development, we tend to develop a code-written specification that actually contains the code style for the entire project group. Because of the different design habits of software developers, if the code style is not unified, the code in a project will be diverse, such as the naming of variables and constants, the annotations of interfaces and implementation classes, when to enter, how to indent, and so on. A wide variety of design style, will be the future maintenance and improvement of the difficulties. We through code review, on the one hand, urging developers to write code in accordance with the specification, on the other hand, developers themselves to form good programming habits. Code-style review, because the content is relatively single, we can often through a number of code review tools to automatically complete, improve the efficiency of the review.

2) Major defects. In some articles on code review, there is a list of the most important flaws that code review should focus on: presence of SQL injection, vulnerability to cross-site scripting attacks, buffer overruns, managed code, and so on. The project team can continuously accumulate major defects in the review project and examine them in each review. Major defect review is a cumbersome and meticulous work, if you can write or use some of the review software, can greatly improve the efficiency of our review.

3 design logic and thinking of the review. In my opinion, this part of the review is the most important and valuable part of code review. The review of code style and major flaws, while important but simple and mechanical, can be automated by software inspection, while the design logic and thinking of the review, but a complex and in-depth review, need to have a certain theoretical depth and coding experience to complete, but especially important for beginners. As mentioned earlier, novices are an unavoidable problem for any project team. Unfortunately, many project managers have done so by handing over simple and small amounts of work to the novice, and handing over a lot of complex work to a handful of veterans. As a result, novices are always new, they don't get enough exercise, old hands work so much that they can't expect to be shared. For this problem, my approach is, through the code review, let the veteran to guide the novice, so that the overall quality of the team to achieve improvement. The concrete method is, after the novice completes the coding, lets the veteran go to carry on the code review, pointed out the novice question, instructs the novice design. Such a process may initially require refactoring, or even recoding. However, after such a process, the novice will gradually become skilled, rapid becoming veteran, so that the overall team quality improvement.

The form and advantages and disadvantages of code review

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

With the above description, we can see that the advantages of code review are obvious. First of all, by reviewing the Code style and specification, it can greatly improve the readability and maintainability of the code. Now the software, often need continuous maintenance and upgrades, personnel changes are inevitable, so the code readability and maintainability is particularly important. Code review is a spur, because it exists, urging developers to consciously standardize coding, develop good coding habits, improve code quality. A noteworthy problem is that if you don't read other people's code, you never understand what is readable, and your code doesn't let anyone read and feedback, and you never know if your code is readable, even if you're a veteran of years of coding. Code review is the solution to this problem, it is worth you to try.

Second, code review is a communication between programmers. Novice can have more opportunities to learn from the veteran and guide, improve their design level (it should be said that this is very valuable to them); veteran through the guidance of beginners, sorting and sublimation of their own design ideas and theories, but also on their own on the other side of the exercise and improve. In addition, when you discover and point out a problem for others, and also warn yourself not to make the same mistake, this is good for both the censor and the censor.

Although the code review has such a prominent advantage, its drawbacks are also very significant, that is, it has to pay such a huge price. When a person completes the code, it requires someone else to read and review, and requires the programmer to complete the corresponding changes, or even refactoring and rewriting, which in itself is a huge price. This is an added insult to the software development project, which is already very stressful for people and time. Time, Labor and code quality, which itself is the fish and bear cake can not be both, the key is how to weigh. Because of this, different companies have chosen different code review strategies.

Not long ago, I listened to a Korean big game software company to talk about their code review. Because the company's software development, time and manpower is not the most critical and critical problem and code quality, so they use a strict code review strategy. Strict code review strategy, one way is to be a person for code review. This way, in the organization of personnel, from the software developers to separate some experienced people, composed of a code review team, dedicated to other software development team code review. In this way, the code review team, as a third party to review the code of each project team, can ensure that the review is fair and impartial, but the pressure is undoubtedly huge (think they want to see so much code).

Another way is to use a project development team to conduct code interoperability for a unit, that is, a person's code, to be reviewed by all members of the team. There is no doubt in this way that the cost of its pay is too great. One way to do this is to combine the pair programming in XP, while the two of people in the programming code each other. The project team with pair programming can try this way, unfortunately, there are too few project teams with pair programming in China. The biggest drawback of the above two code reviews is accountability, that is, the reviewer does not have much responsibility to find the subject of the reviewer, and finds that the problem is not of any benefit to the reviewer but rather to the grudges of the reviewer, who, on the other hand, does not find the problem and assumes no responsibility. Such a result leads to a mere formality of code review: Censors hastily reviewed and the parties were happy and the problem remained.

To sum up, although the advantages of code review is obvious, but the above several forms can not be accepted by the common software development team, I sacrificed my best practice: In Groups, team leader responsibility of the code review form.

Best Practices for code review

Code review is a cost, even sometimes huge, so code review is not frequent, the best one code only review once. At the same time, the code reviewer should be responsible for the code under review, that is, be able to boldly review and point out the subject of the reviewer, and ask the reviewer to rectify the deadline. At the same time, the censor should be held responsible for any defects in the code under review. The code review is acceptable only if the above three conditions are met. There is no doubt that the team leader of the project development team is most suitable for this responsibility.

A project development team, according to its functional division, can be divided into several groups, each responsible for a sub module. In such a group, the team leader is undoubtedly the most experienced developer, and it is appropriate for him to organize and guide other members. Group members do not have too many, often 3~5. The team leader does not assign too many development tasks, and his main job is to instruct and oversee the development of other members of the group. By freeing him from heavy development tasks, he can have more energy to guide the design of other members and review their code. In the end, he is responsible for the code quality of all members of the team, and is checked by the project manager or quality management staff to check the overall situation.

If you're just a small project with a total of 5 people, then you don't have to do this grouping. As a project manager, you are the team leader who guides and supervises your members. This arrangement is because in modern management theory, one person can only manage 5 people, and more than 5 people should be managed in groups. And if you're within 5 people, of course you don't need to separate.

As a leader, you can effectively review and manage your team members. At the same time, because you are responsible, you have to work hard and effectively to complete the review. Through the organization of the above, code review can be easily and effectively carried out in the project team, thereby effectively improving the code quality of software development from the management.