How to Improve code quality (management): Code Review

Maybe you are a project manager, maybe you are a backbone member of the project, or a development team lead. After I published a series of articles "How to Improve code quality", many netizens complained to me that he could not grasp the code quality of the entire project team member. I think this is also a common problem for all project teams. It is usually manifested in the following problems:

Common Problems in software projects

1) newbie

It is inevitable that any project team members will be new to new students who have just graduated from college. Because the software development time is too short for these beginners, the technology is often not mature and there is no good development habits, so the quality of coding is poor and there are many problems. They often become the "chicken ribs" of the project team, and the quality of the project cannot be guaranteed when the project is used up.

2) personnel changes

Personnel changes are inevitable for a software project with a longer maintenance period. Old employees are transferred to other projects and new employees are responsible for taking over their jobs. In my project team, the number of people transferred reached 90%. The only thing I did not transfer was myself. When the new employee takes over the old employee for code maintenance and even continues new development, a large amount of inferior Code may also appear due to the misunderstanding of the original code and design ideas.

3) Writing nonstandard code

Even if the effects of the above two problems are removed, the code written by the project team members will also have problems. At the beginning of project development, we often develop a code writing specification, but in the project development process, many members tend to ignore these code specifications and write them at will. Writing code at Will will reduce the readability, maintainability and ease of change of the Code. So what management measures should we adopt to ensure code standards and improve the quality of code?

The above problems are also the problems that I keep exploring and thinking about during project development. Some experienced project managers have given their solutions, that is, "code review ".

What is code review?

Code Review (Code Review) is also called "code review". The basic idea is that after developers write their own code, others will review the code they have written, this effectively discovers defects in the code. A basic theory of code review is that the sooner we discover defects in the Code, the lower the cost of solving them. Code reviews are often divided into the following:

1) code style

At the beginning of project development, we often develop a code writing specification. In fact, this code specification contains the code style of the entire project team. Due to the different design habits of software developers, if the code style is not uniform, the code in a project will be varied, such as the naming of variables and constants, comments of interfaces and implementation classes, carriage return and indentation. A wide variety of Design Styles will inevitably bring difficulties for future maintenance and improvement. Through code review, on the one hand, we urge developers to write code in accordance with the specifications, on the other hand, it also makes developers themselves form good programming habits. Code-style review, because the content is relatively simple, we can often use some code review tools to automatically complete, improving the review efficiency.

2) Major defects

In some articles on code review, a common list is listed, which describes major defects that should be paid attention to during code review. They include: there are SQL injection, cross-site scripting attacks, cache overflow, managed code, and so on. The project team can continuously develop review items for major defects and check each review one by one. Major defect review is a tedious and meticulous task. If some review software can be written or used, it 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 the code review. The review of code style and major defects is important but simple and mechanical, and can be automatically checked through software. The review of design logic and ideas is complex and in-depth, talents with certain theoretical depth and coding experience are required, which is especially important for new users. As mentioned above, newbie is an inevitable problem for any project team. However, unfortunately, many project managers only give some simple and a small amount of work to the novice, and assign a large number of complex work to a small number of veterans. As a result, new users are always new, and they have not been trained enough. veterans are exhausted and cannot expect new users to share their work.

My solution to this problem is to let the veteran guide the novice through code review so that the overall quality of the team can be improved. The specific method is to let the veteran review the code after the novice completes the code, point out the problem of the novice, and guide the novice design. Such a process may need to be reconstructed or re-encoded at first. However, after such a process, the novice will gradually become skilled and quickly become a veteran, improving the overall team quality.

Code review forms and advantages and disadvantages

After the above descriptions, we can find that the advantages of code review are obvious. First, the Code style and specification can be reviewed to greatly improve the readability and maintainability of the Code. Nowadays, software often requires continuous maintenance and upgrade, and personnel changes are inevitable. Therefore, code readability and maintainability are particularly important. Code review is a spur. Because of its existence, developers are urged to consciously standardize code, develop good coding habits, and improve code quality. It is worth noting that if you do not read other people's code, you will never be able to fully understand what readable code is, and your own code will not let others read and give feedback, you never know whether your code is readable, even if you are a veteran of coding for many years. Code review solves this problem and is worth trying.

Second, code review is a communication between programmers. New users can have more opportunities to learn from and guide their veterans and improve their design level (it should be said that this is very valuable to them, sort out and sublimate your own design ideas and theories, while also training and improving yourself. In addition, when you discover and point out a problem from someone else, you are also warning yourself not to make the same mistake, which is beneficial to both the examiner and the Examiner.

Although code review has such outstanding advantages, its disadvantage is also very significant, that is, it needs to pay such a huge price. After a person completes the encoding, another person needs to interpret and review the code, and ask the programmer to complete the corresponding modifications, or even refactor and rewrite the Code. This is a huge price in itself. This is undoubtedly worse for software development projects that are already staffed and time-consuming. Time, manpower, and code quality are both essential to the balance between fish and the bear's paw. Because of this, different companies have chosen different code review policies.

Not long ago, I heard a large Korean game software company talk about their code review. Since the most critical issue in software development is not time and manpower but code quality, they adopt a strict code review strategy. Strict code review policy. One way is to review the Code by a dedicated person. In this way, in the form of personnel organization, the software developers separately put forward some experienced people, form a code review team, full-time code review for other software development teams. In this way, the Code Review Team reviews the code of each project group as a third party to ensure that the review is fair and equitable, but the pressure is definitely huge (think about how much code they want to view ).

Another way is to perform Code mutual check in the unit of a project development team, that is, the code of a person should be reviewed by all the members of the group. This method is undoubtedly costly. A work und for this method is to combine Pair Programming in XP, while two people in Pair Programming perform Code mutual query. The program team using Pair programming can try this way. Unfortunately, there are too few projects using Pair Programming in China. The biggest drawback of the above two types of code review is the responsibility system, that is, the examiner does not have much responsibility to find the problem of the examiner. The examiner finds that the problem does not have any benefit to the examiner, but does not complain to the examiner; on the contrary, the examiner will not be liable for any problems found. Such a result leads to code review in the form of the form: the reviewers submit a rough review, all parties are happy, the problem still exists.

To sum up, although the Code review has obvious advantages, the above forms cannot be accepted by common software development teams. In this regard, I have offered my best practices: in groups, code Review Form of the leader's responsibility system.

Best practices for code review

Code review is costly, and sometimes huge. Therefore, code review should not be frequent. It is best to review the Code only once. At the same time, the Code reviewer should be responsible for the code being reviewed, that is, the examiner should be able to boldly review and identify the problems of the examiner, and require the examiner to make rectification within a time limit. At the same time, the examiner should be responsible for any further defects in the code under review. We can accept the code review only when the above three conditions are met. Undoubtedly, it is most appropriate for the project development team lead to assume this responsibility.

A project development group can be divided into multiple groups based on its functions. Each group is responsible for one submodule. In such a group, the team leader is undoubtedly the most experienced developer. It is appropriate for him to be responsible for organizing and guiding other members. Too many group members, usually 3 ~ Five members. The team lead should not assign too many development tasks. His main task is to guide and supervise other members of the team for development. Free him from the 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 the members of the team. The project manager or quality administrator conducts spot checks to check the overall situation.

If you are only a small project with a total of five employees, you do not need to group it like this. As a project manager, you are the group leader, guiding and supervising your members. This arrangement is because in modern management theory, a person can manage up to five people, and more than five people should be managed by group. However, if you have five employees, you certainly do not need to split them.

As a leader, you can effectively review and manage your team members. At the same time, because you are responsible, you have to complete the review carefully and effectively. Through the above organization, code review can be easily and effectively carried out in the project team, so as to effectively improve the code quality of software development.

 

Reprinted from: http://fangang.iteye.com/blog/599976