Introduction:

Recently, I had a chat with the developers in the team. I saw that many developers have aspirations to improve their code skills, but the fast pace of business does not give them much time to stay. In this case, how to create a strong atmosphere for the team to communicate with engineers?

There are several approaches, and the most recognized or used one is the CodeReview activity.

So what does CodeReview bring to the team? What teams need to conduct CodeReview activities? How to conduct CodeReview activities effectively? Which way would be better?

This week, we invite Liu Yongli from Tencent MIG Wireless R&D department to share her valuable experience in CodeReview practice.

The body of the

In order to study the practice of CodeReview in a grounded way, the author chose the “Mobile Butler High-authority Application Group” as the pilot team to carry out the activity. This team is highly identified with the CodeReview activity and is willing to continue to improve. After one year of operation, the team has achieved remarkable results in the operation of CodeReview activity.

Next, based on the pilot experience, the author summarizes the views and thoughts on the practice of CodeReview, hoping to provide reference for teams who want or are carrying out CodeReview activities.

What can CodeReview bring to the team?

By participating in the actual practice and discussing and thinking with team members, we believe that the ultimate role of CodeReview will be to facilitate engineers’ daily code communication and personnel growth, and at the same time serve as an auxiliary means to check product quality.

But in general, a lot of team in the early stage of the CodeReview key is to find problems (code specification, potential defects, bugs, code design, etc.), and later as the problem of habit gradually reduce and gradually develop, engineer, build will be converted to the key communication culture, when there are a large number of new people to join, mid reasons will rise again as the key point, so after the beginning.

To sum up, in most cases, problem finding will be the original intention of CodeReview activities, but in the later stage, its greater significance will evolve into the cultivation of soil for engineers’ communication and the promotion of personnel growth.

Ii. What kind of team needs to conduct CodeReview activities?

CodeReview is a recognized best practice in the industry, and it would be great if every team could use it. However, since it is closely related to the “people” factor, the effectiveness of CodeReview has a great deal to do with team status, technical beliefs, and leader appeals. Today, I would like to share my thoughts on “what kind of team needs” and “what kind of team doesn’t fit right now”. We welcome more exchanges and discussions here.

From the perspective of code quality improvement, I recommend the following types of teams to make CodeReview activities work:

  1. Technology-driven teams: generally involve a lot of underlying logic of the system, the functional path is difficult to be covered by testing, and product quality problems are often fatal, so such teams need more rigor of development code and related code quality assurance activities. The Mobile Manager high-privilege app group falls into this category.

  2. Public service team: generally serve multiple teams, once quality problems occur, the impact will be relatively wide, so in addition to testing to check, through CodeReview activities to improve the quality of development is very necessary.

  3. Test-missing teams: These teams are at high risk of quality problems being brought online due to the lack of testing. Self-checking during development is strongly recommended.

  4. Newbie intensive team: the readability of new code is often poor, especially the organization can provide timely correction to help new recruits develop good coding habits. Also, if the code produced by the team is readable, the newcomers can get started faster.

  5. Any willing team: a team or leader who believes in the meaning of CodeReview, or whose members are committed to improving code quality.

CodeReview activities are closely related to the human factor. Based on the subjective characteristics of CodeReview activities, the author believes that the following types of teams are not suitable for CodeReview activities for the time being:

  1. Disapproving teams: teams where the leader and the backbone of the team disagree with the meaning of CodeReview, and such teams have great challenges to drive and persist.

  2. Tired teams: These teams do not have the necessary continuous improvement mechanisms in place, and are swamped with requirements communication to implement changes and optimizations on a daily basis. Naturally, code quality improvement activities can hardly be added to the backlog.

  3. Innovative teams: The important task of these teams is to get the product to market quickly and prove its value, so the code needs to be agile enough that temporary confusion is acceptable.

To sum up, the author suggests that when considering whether your team should implement CodeReview, you can make a comprehensive consideration based on the actual status of the team. But generally speaking, if there is no problem with the subjective will of the team, it can be carried out boldly.

Iii. How to effectively carry out CodeReview activities?

To effectively operate CodeReview activities within the team, there are four essential elements (figure below). If your team is not running the CodeReview campaign effectively or is having trouble, this section is for you to take a closer look at.



1. Code specification: clear Coding rules

If the team Coding standards were not defined at the beginning, there would be two situations during the review: Is a variety of different opinions are difficult to quickly reach an agreement, effect on the efficiency review, another is the team won’t pay attention to the code review, if the former is still good, after all, everyone is focused on what is good writing or for this problem, as long as the way to establish the Coding rules, the problem can be solved soon. The latter happened to a team I followed: Since the team did not have clear Coding rules in the early stage, most developers directly ignored the problems related to norms. After CodeReview had been running for a period of time, there were still problems such as non-standard naming and poor readability in the code, which directly affected the effect of activities, which we did not want to see.

We don’t need a code specification because we don’t want to waste time obsessing over details like fewer Spaces and more lines. I personally don’t agree with this view, because code specifications include not only constraints such as whitespace and characters, but also comment requirements, naming conventions, whether words are named to make sense, code structure, and other factors that affect code readability. If there are no basic rules in these areas, The two situations mentioned above (too much controversy or completely ignored) will definitely occur, with predictable results. Therefore, you can customize certain rules according to your own views or needs, but you cannot do without Coding rules.

2, review guide: eliminate confusion and confusion

The Viewing guide is also known as the CodereView-Checklist. Not all members of a team are old drivers. Many students have no experience in code review, so they often don’t know which points should be checked.

At this time, it is necessary to formulate a checklist based on their own business characteristics and the pits that the team has previously stepped on:

  • What writing might cause poor performance?

  • Which interface should be used with caution?

  • What design practices should be avoided?

  • What habits are likely to cause memory leaks?

  • Wait…

In this way, inexperienced people who do not know what to review can have a clear target and gradually accumulate experience in the process.

The following is the change in the number of questions CodeReview found before and after a team created the review guide, demonstrating the importance of creating the review guide.



Of course, some people say that my team’s code review is done by senior cadres, there is no situation that I do not know how to review.

However, I would like to say that the time of key staff is precious after all, and they are often very busy. Why not invite more members to participate in the review work together? After all, CodeReview is not only about finding problems, but also about communicating and learning codes!

3. Summary and optimization: transparency and continuous optimization(Very important)

We have seen many teams fail to adhere to CodeReview activities or gradually become a formality. In fact, the main reason is the lack of regular review and summary in the process, so that they do not know how to effectively promote and help the team to operate better.

In order to better promote this activity, the mobile Butler high-authority application group set up the CodeReview organizing Committee. This organization will summarize the operation of CodeReview every month, analyze problems, solve problems, and continue to optimize, and its final effect can be highly recognized both inside and outside the team. It can be said that summary optimization this link has played a very key role.

4. Incentive mechanism: Stimulate subjective initiative

Since CodeReview itself is closely related to people’s experience or consciousness, many times we will be worried that we cannot mobilize the enthusiasm of students to develop, so in order to let everyone better participate in this activity, we generally need to formulate corresponding incentive mechanism. Some people also said that if the leader is forced to link with the assessment, there is no need for this. Yes, but from another point of view, isn’t linking with the assessment another way of “motivation”? Haha…

There are many kinds of incentive mechanisms, generally speaking, they are based on the regular review of CodeReview based on the actual situation of the positive performance of the students to give a certain gift award (the choice of gifts depends on the economic status of the organization, haha).

The team followed by the author will conduct quality star election according to the number of CodeReview submissions and the number of problems found every month. The gifts include books, dolls, badges, etc. The results are good, and the methods are for your reference.

In summary, code specifications, review guidelines, summary optimizations, and incentives are all critical to the success of CodeReview activities, but the team can customize each of them based on industry practices.

Four, CodeReview many ways, which will be better?

The industry operates CodeReview in a variety of ways: mandatory & optional, online & offline meetings, small segments & large modules, pre & post, high & low frequency, and so on… It is understood that each form has its own market and is being used by different teams.

Next, the author analyzes the advantages and disadvantages of various forms from a personal perspective for your reference:

  1. Mandatory & Non-mandatory: According to experience, it is recommended to adopt mandatory requirements in the early stage of CodeReview startup, otherwise it is difficult to carry out effectively. Stick with it for a while and then think about degrees of freedom after you get into the habit.

  2. Small fragments & Large Modules: If you want to expose problems more fully or reduce the difficulty of review, it is recommended to adopt a fine-grained approach, i.e. small fragments submit small fragments for review. If you pay more attention to the overall design and logical thinking of learning and finding problems, then you can use a modular approach to review. But a lot of times the two can work together.

  3. Online communication & Offline meeting: If you want to improve efficiency, it is suggested to use online communication. Here we recommend the company’s Code platform, which has complete functions supporting CodeReview. If you prefer to find fault with all the members of the kind of pleasure, then you can use offline meetings to carry out, but the way of meeting, the general cost is higher, can see the acceptance of the team.

  4. Before & After: This refers to before or after the release. The unified approach to CodeReview after release is more of a code exchange activity than a code quality check. On the other hand, if you CodeReview your code before release, you can do a good job of checking quality issues. This is a tradeoff between time and mass.

  5. High frequency & Low frequency: WHAT I recommend is code communication every day, so the higher the frequency, the better. Specific arrangements can be made according to the actual situation of the team.

  6. In addition, some teams also adopt the CodeReview method, in which the owner of the module checks the quality. This method is mainly considered from the perspective of quality risk avoidance. The owner checks whether there is any quality problem before the code is submitted and can only release it after confirming that there is no problem.

Finally, the CodeReview method recommended by the author is mandatory + beforehand + small fragments + online communication + high frequency. Meanwhile, it will be better if the code communication activity can be carried out in combination with the offline large module method.This experience comes from the grounded practice of the mobile Manager high-privilege application group.

However, different team states allow different selection methods, so it is up to the team to decide which combination of methods to choose.

V. Conclusion summary

In order to bring some help to readers, the author has reviewed and revised the article repeatedly. No matter whether the ultimate goal has been achieved or not, at least I have tried to do my best in attitude and behavior.

Similarly, the author believes that if you want to make it easier for others to read and understand the Code, review is also necessary to achieve the goal.

So let’s get the CodeReview activity flowing

If you think our content is good, please scan the QR code to appreciate the author and share with your friends

This article is the exclusive content of Tencent Bugly, please reprint at the beginning of the articleNote the author and source “Tencent Bugly(http://bugly.qq.com)”