1. what—什么是CR

Codereview (CR) has long been seen in the software industry as an effective way to improve code quality and as a representative of an engineering culture. The definition of CR is as follows:

Code review refers to the systematization of source code during software development. The usual purpose is to find defects in the system, ensure the overall quality of the software and improve the level of the developers themselves. Code Review is a lightweight Code Review. The costs of a lightweight Code Review are significantly lower than those of a formal Code Review and can have a more positive effect if the process is correct. Because of this, lightweight code reviews are often introduced into the software development process.

From the above explanation, you can basically see the core points of CR:

1. CR should be in the research and development process, not after the end of the project, that is to say, CR should exist in the research and development process, only in the process to ensure the final delivery results, rather than the final fix and self-pity;
2. The purpose of CR is to find system defects in advance and solve them in advance. In fact, the purpose of CR is not only to find problems, but to communicate and cooperate with developers. The main purpose is to be responsible for the quality of the system, but the benefits will far exceed this point.
3. CR is the check and communication of lightweight code, so in order to complete a good quality CR, the prerequisite is light enough, which is reflected in two aspects: One is the amount of code review. It can be imagined that if the amount of code is too large, even more than hundreds of lines, people will feel tired, and the quality of review will naturally decline, and finally become a cursory form. That is to say, in most cases, CR needs to be implemented in small steps. Second, the code structure is light-weight enough, this light-weight mainly means that the code structure is clear, at least comply with the principle of sole responsibility of class and the number of reviewers should not be too much and other basic development constraints. Only if these prerequisites are satisfied, the code structure is clear, more enable reviewers to understand what you want to express, and, Clear structure will improve the beauty of the code, and naturally improve reviewers’ sense of participation and happiness;
4. Finally have so a word is “if the process is correct, it can play a more positive effect”, just as everything, half angel and half devil, only according to the situation of the team to choose the right means of CR, to gain the effect of making profits, or it will become a burden, as team deviate from normal orbit.

It can be found that if CR is properly introduced into the research and development process, it will undoubtedly greatly enhance the code quality of the system and promote the development of the team. But at the same time, we also need to determine the plan according to the reality of the team.

2. Why — Why was CR introduced

As for why CR should be introduced, I have been thinking about this question. The biggest obstacle to the implementation of CR is that it takes time to implement the process, and this part of the process must be very heavy, and the team must be willing to pay for the introduction of this process in terms of time. In addition, improper CR approach will certainly cause many negative effects:

1. In the case of a CR process error, the following scenario must occur:

A: This code needs to be changed here, here and there;

B: The LZ code is very good, you can up, no can no bb

A: You must change this code;

B: I feel very complicated and tired mentally

If CR execution process is wrong, will appear this kind of circumstance, if appear this kind of circumstance, the implementation of the CR is necessarily will fail, serious word will damage the friend feeling, also affects the development of team atmosphere, but I think, appear this kind of circumstance, there is a fundamental reason lies in the CR process at each stage due to gather something different, In layman’s terms, you are talking about A and TA is talking about B. My thoughts on how to solve such A problem will be given below.

1. Too much to take up development time, for developers, need most is quiet time to develop, if there is no focal point in the process of CR, there is no admitted on individual points of discussion, it was failed to CR, because a lot of crowding out development time, is brought about by the developers need to stay up late to work overtime again, over time, Is in the heart to build psychological defense and barriers;

Of course, there should be many negative effects brought by the introduction of CR. But what are the benefits of CR? The list should be random:

1. Improving code quality

   This is an important point, which has already been stated in the What section and needs no further elaboration;

2. It is conducive to the landing of norms

   There are development protocols in Java, but inevitably some of them are not followed. A big reason is that each developer remembers or understands different parts of the protocols at a cognitive level. For example, one person may only understand five, while another may understand eight. With CR, developers would have the opportunity to collide and communicate, even if 5+8 doesn’t equal 13, if 5+8=10, it would be 10 for everyone, not 5 and 8, and the benefit would be huge. So, for the team, the specification is really on the ground. Similarly, JAVA development specifications need to be versatile, with most of the developers, and each team will be according to your own business scenarios and formulate the corresponding development code, and this part also need a CR to carry, landing ditto below analysis, everyone in their cognitive structure ownner part of take out again to communicate, It will undoubtedly accelerate the landing of norms;

3. Deeper understanding of the business

   If it is a formal CR (round code-review), namely a small round table CR, multiple developers will participate in the CR, and it is necessary to have code walking, so when walking through the code, I will naturally explain my understanding of the business and the current business process. I always believe that, Reading and writing is the progression of different levels of understanding of a thing. We will write code according to the current business, but if we can explain it according to our own understanding when we walk through the code, we will gain more for ourselves. In addition, participating in CR also allows me to know the thinking and coding design of other students in other businesses, which is a huge learning opportunity. We always have such anxiety, total feel every time do is a XXX module, the overall lack of understanding, the feeling is always a code farmer, I think if you have such an opportunity, perception of the whole system and the business will strengthen, if a development team is a warrior, the fighting capacity is huge.

4. The enhancement of expression and communication ability

   CR is a collaborative process involving multiple developers. In the process of code walking, our expression ability will definitely be improved. We will think about how to express our current design and the current business problem to be solved to others accurately and clearly. At the same time, when faced with a challenge, how to explain the current logic and thinking to the challenger, and if the challenger is more reasonable, how to readily accept and express gratitude to the proposer is a sign of high EQ.

5. The opportunity to learn from those who came before us

   At work, new people always want to learn from the experience of seniors, due to the lack of appropriate questions and scenarios, sometimes asking seniors can only stay on the surface of communication, unable to conduct in-depth analysis of specific problems and scenarios. CR is a good opportunity, when there is a disagreement, it is a specific problem scene, and the newcomers can learn their design thinking and their solutions from the seniors on this scene. Bit by bit accumulation, there is no doubt that there will be qualitative changes for the newcomers, and for the team, the inheritance of the old with the new is completed imperceptibly. Therefore, CR is a concrete and real learning opportunity, and I am eager to learn their experience and design methods from the predecessors, which is also my strong motivation to land CR.

6. Sense of ceremony

   We need a sense of ritual in our lives. We have anniversaries to remind ourselves of the sweetness of life. In the same way, I think CR is a rite of ceremony in the engineering culture. It’s a happy thing for developers to gather their ideas together, and it’s just a belief in the engineering culture that makes it happen.

These are the advantages I think CR can bring, and I think CR will bring huge benefits if it is implemented. If you want to explain why CR was introduced, you need to answer the question of what CR can bring to the team:

Finding problems is always just a by-product of CR!

In most cases, problem finding will be the original intention of CodeReview activities, but in the later stage, it will evolve into the cultivation of soil for engineers to communicate and the promotion of personnel growth. 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, mid – when there are a large number of new people to join, find the problem will rise again as the key point, so after the beginning.

CodeReview’s ultimate role will be to facilitate daily code communication and staff development, as well as to assist in product quality control.

3. Who — the main body involved in CR

CR is a collaborative activity, and before implementing CR, it is necessary to make clear the participants in CR. CR is related to the status of the team, the team’s technical beliefs, and the team’s demands. Since linking with “people” is also essential to the “people” factor, of course, it is also essential to the code and the various personnel involved in this activity.

3.1 What kind of team needs CR

Teams that invest in CR naturally expect it to be an aid to solve certain problems. That is to say, teams that currently want to use CR to achieve further breakthroughs need to introduce CR for the following types of teams:

1. ** Technology-driven teams: ** generally involve more underlying logic of the system, functional paths are difficult to be covered by tests, and product quality problems are often fatal, so such teams need more rigor in the development of coding and related code quality assurance activities;
2. ** Public service team: ** Generally serves multiple teams, once quality problems occur, the scope of 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: * * team due to A lack of formal professional testing link, the development of self-test easily lost in the development of their logic, and because developers often only familiar with the current business module, can only cover the current business module test, in view of the business of A and B pair may cause quality problem may not be able to cover in the self-test, quality problems to the risk of online will be very high, Communication collisions are strongly recommended in CR to reduce this risk;
4. ** Newbie intensive team: ** Newbie’s code readability is often poor, which requires timely correction by the organization to help newbie 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.

So what kind of team doesn’t need to introduce CR?

1. ** Disapproving teams: ** is a team where both 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. ** Overwhelmed 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: ** These teams are focused on getting the product to market quickly and proving value, so they need to be agile in their code writing, and temporary confusion is acceptable.

3.2 What code needs to be introduced into CR

The other subject of CR is definitely the code, which is also the subject of discussion among developers, whether all code needs to be CR, in my opinion not.

3.2.1 Which codes need to be introduced into CR

Core link business code

In complex business scenarios, the code responsible for major business functions needs to be taken out of CR, so how to measure which part is the core link? From the point of view, the business flow distribution in the Internet applications have 28 principle, namely 80% flow in 20% of the data (business), then this is the need to take out 20% of the business code of CR, this part of the code for the function of the current iteration core, most care is also the user points, at the same time also is the focal point in the software business cycle, It is also the strong functional requirement of PD, which naturally needs to be paid special attention to. If there is an online risk, the loss will be huge.

System underlying framework core code

From the perspective of system infrastructure construction, PD’s requirements are generally functional, ignoring the non-functional requirements of the system, which are the robustness given to the system by the developer. This part is related to whether the software system can provide strong vitality, and is also regarded as the engine of the system. Project management in collaborative platform, for example, three phase of the project – a milestone in the specification, create milestone and milestone sequential rules through milestone template check mechanism, is seen as the phase of the project of “infrastructure”, of course also should be take out CR, if there are problems, will certainly “wind and rain, were to collapse”!

In fact, the above two types of code can be identified in the technical proposal review and are required for round CR.

3.2.2 Which code does not need CR

Business literal code

Referring to the flow distribution, there are always some business functions that are not the core functions that users care about, but only exist because of the integrity of the system function, or the business process is very simple, from controller- >service- > DAO to PRD “translated” code (called business literal code), Objectively speaking, round CR does not need to take a long time. But isn’t CR definitely not needed? Not necessarily, but the process does not need to be so heavy, you can use deskmate CR (i.e. communication between deskmates), that is, peer programmer (pair programming), simple and efficient communication between two people can be.

3.3 Who needs to participate in CR

After all, CR is an activity related to people, and the quality of CR is also linked to the efficiency of communication and collaboration between people. Therefore, in order to obtain high-quality CR, it is necessary to clarify the roles of personnel involved in CR and assign corresponding responsibilities.

Speaker

The speaker is the developer of the current walking code, which I prefer to call the speaker rather than the person being reviewed. A speaker is someone who appears in academic conferences and various technical conferences to explain his or her own ideas and concepts. I also think that every person who reads the code should have the confidence to present their ideas to other developers in a reasonable, clear and logical way. If they are not confident, how can they convince others? The code should be the developer’s art. Therefore, speakers have the following responsibilities:

• Should do
  1. Before CR, there should be a clear context in mind, and it is better to say it silently in my heart. This is the responsibility of the speaker, and it is directly related to the efficiency and final effect of CR.
  2. Improve the readability of code, learn to take another’s place, code structure is a reviewers mess, CR is definitely not allowed to pass, how can let others be interested in seeing the mess?
  3. Be more confident. This is an opportunity for every developer to communicate and express themselves. There is always someone teasing programmers that they are boring and not good at words.
• Shouldn’t have done it
  1. This is undoubtedly a waste of everyone’s time, if in this case, reviewers can be reasonable to give suggestions and urge them to realize the problem, CR is ultimately a matter of coordination, so someone must abide by this basic rules of the game.
  2. Don’t turn your back on the advice of others. Embrace the sound advice of others because it can be a great learning opportunity.

reviewers

Reviewers refers to those making suggestions for developer code, where this role can also be separated into two categories:

• reviewer-ownner

  This character is considered to be the person most familiar with the current system, arguably the founder of the current system, familiar with its various neural pathways. Therefore, at reviewer time, we need to observe whether the current developer’s code will harm the existing architecture. In addition, such a role should also have the ability of business perception. In addition to fulfilling current requirements, such a role should predict the trend of current system functions and judge whether the current developer’s code can be extended and supported for future business by its own business perception ability. The cardinal rule for this type of role is to think big.

• reviewer-expert

  As a matter of fact, the role of Reviewer – Ownner is no longer a front-line developer. An experienced developer is definitely needed in CR, and this role will provide detailed suggestions on specific points of the developer’s code based on her own experience during CR. These suggestions are the key elements that drive the team’s code specification and quality. In this role, the basic principle is to “start small”.

What are the responsibilities for this role?

• Should do
  1. Responsible for the system, make reasonable evaluation of speaker code and give suggestions;
  2. Do not deliberately find problems, of course, the main purpose of CR is to find problems, but in this process, we need to ensure the balance of mentality, deliberately doing one thing will be to lose one thing and lose something more important, I firmly believe that problems are always a by-product of CR.
  3. Don’t according to your own style to observe other people’s code, the code is each developer works of art, each people have own when writing code coding style and design ideas, if you start with colored glasses to see, if any place will feel not pleasing to the eye, and ignores the important things, lost the focal point of CR. For Revierers, it’s also a way to learn about other ideas.
  4. Do not question the ability of others and the mentality of attack, this mentality is a big no-no in CR process, everyone involved in CR should be simple, trust and respect each other. If this mindset exists, it can lead to unnecessary debate and even make CR a psychological burden;
  5. Don’t argue for too long on uncertain issues. Arguing for too long on some specific details will block the whole process and cause negative and negative effects. At this time, someone needs to interrupt and shelve the dispute for the time being.
• Shouldn’t have done it
  1. Only make comments without giving specific plans or opinions that can be implemented. We all hate talking orators. For each participant, we hope to learn effective solutions and reviewers from others during CR process. In the process of CR, we should face specific questions, for reviewers, it is perfectly possible to make an analysis with the developer for specific questions. Further, specific suggestions will be given based on reviewers’ existing technical cases, which is an opportunity for further development. If you just talk, after all, there are so many steps from a request to the final completion of the request, you can talk too much, but basically bring nothing;

recorder

During the CR process, it is natural to record subsequent actions, meaning that such a role should be responsible for this. Such a role is needed only because the speaker and reviewer need to communicate and express in the CR process. If they stop to record and distract their attention, the whole process will not be smoothly completed and the pleasure of CR will be greatly lost. There are responsibilities for this role:

• Should do
  1. Grasp the speaker and Reviewer disagreement, which is the product of CR and the breakthrough point to promote the evolution of the system, the recorder needs to record it in detail as a follow-up action.
• Shouldn’t have done it
  1. Think in CR responsibility is not important, to the recorder, ** do not think, he is just a record of personnel, on the ground, ** because once there is such a mentality, will inevitably cause in the CR process of mental disconcentration, miss a lot of meaningful point, in fact, for the recorder, You are also a reviewer, but you need to take part of the recorder responsibilities.

The above four roles will exist in the CR process, but the four roles are not necessarily multiple people, each responsible for one role. For example, in pair programming, there are usually only two roles. Then the speaker is responsible for the walking of the code and the recording as a recorder. The scope of responsibility for the role must be clear, otherwise in the CR process will be headless, unable to find the power point.

4. Where — CR is performed on different R&D nodes

CR can be a very formal in the conference room, also can be in deskmate between colleagues, that is to say, according to the site of CR can categorize CR, in fact, this classification from the side also reflects the different business scenarios should choose what kind of form of CR, CR are classified in this article, I carry on the summary:

1. Deskmate (CR), also known as pair programming: Discuss a problem between deskmates
2. Just-in-time (over-the-shoulder) code review: current code must be reviewed before moving forward, blocking
3. Tool-assisted code review: After code has been submitted, developers can continue coding with reviewer availability for review
4. Round -CR: Organize meetings to conduct CR on core code

If you end up in pair programming because the CR process is a waste of time, it will be superficial and ineffective. Pair programming typically involves a developer knowing that they are stuck on a problem and going to talk to someone else, with a strong assumption that the developer will initiate CR only if they know there is a problem or that the code is not working. In fact, this strong assumption is a hazard factor, once there are assumptions must be hidden dangers. It is similar to the strong constraint in coding that once the system is assumed to be non-empty, then once the line is empty, it crashes instantly. In fact, most of the time, people get into the “I thought it was right, but it was wrong” situation. If developers can figure out what’s wrong and fix it, why are there so many online glitches and risks? Relying on human nature is inherently dangerous, and relying solely on CR in the form of pair programming is inherently false.

The applicable scenarios for the four different forms of CR are summarized as follows:

1. Pair programming

   This code review approach is useful when you need to solve a complex problem. Bringing two people’s brains together in a careful search for a solution increases the odds of success. By having two minds think about the same problem and discuss possible solutions with each other, you are more likely to cover some of the boundary cases of the problem. Pair programming is suitable for situations where two developers with similar levels of experience are working on complex business problems.

2. Instant over-the-shoulder code review

   Synchronous code reviews can also be effective if the code writer is inexperienced and needs major improvements. If an experienced senior developer is going to review a piece of code written by a junior programmer, working with the senior developer to improve the code after the junior programmer has written it is far more efficient than the junior programmer alone. However, there are also situations where people need to be disturbed, affecting work efficiency. For developers, if review is not approved, they cannot proceed, which is blocking.

3. Tool-assisted code review

   Tool-assisted code review is asynchronous, with developers submitting code and waiting for Reiewer to view it. Developers don’t have to rely directly on censors, and they can all do their own work on their own schedule. One drawback is that, after review, developers need to switch back to what they thought before.

4. Round-table CR

   Code for core processes and system infrastructure often needs to be reviewed in a formal form to avoid risks as early as possible.

The application of the different forms of CR scenario requires according to the current code to solve the problem of attribute selection, there is no fixed way, only the right way, such as “literal translation type business code” pair programming method can be used to solve, research and development in the process of agile enough, can choose the parts of nodes “asynchronous” in the form of CR The roundtable CR can be introduced in the core Business Code and Infrastructure code.

5. When — When will CR be introduced

When to introduce CR, here, from two dimensions:

1. For the team

   For the team, CR will inevitably take up part of the r&d time. What kind of team needs to be introduced, and what kind of team needs to be introduced in THE Who. It all boils down to a willingness to cultivate an engineer’s culture and a team’s technical beliefs, and a willingness to pay for the time spent doing so. In addition, if the business is developing rapidly and supporting the business development is a higher priority, it is also correct not to introduce CR, only the most appropriate, not the most correct.

2. At different points in the development process

   In part 4 Where, four common CR modes are summarized. These four CR modes also exist to solve different problem scenarios, and appropriate modes should be selected according to different scenarios. At least from the moment the technical solution is identified and the business process is sorted out, it should be clear which code implementation is required for round-CR, because if the core of the current system iteration is not clear, the technical solution is bound to fail.

6. How– How to do CR

As for how to carry out CR, several key elements of CR are discussed in the parts of What, Why, Who and Where respectively. My thoughts on the implementation of CR are given below.

6.1 Preparation for CR

1. The team mind is aligned

   CR is a team collaboration process. In order to achieve high efficiency and high returns, the starting point must be that team members reach a consensus on the level of consciousness, which requires a spirit of contract. In CR, each person’s role, such as speaker, Vision-Ownner, Vision-Expert and Recorder, has given corresponding responsibility scope in the “Who” section, including the discussion of what should be done and what should not be done. Each role, according to their role should be agreed, and strive to take the initiative to undertake this part of the responsibility.

2. Reasonable choice CR

   If each project we need CR (or simply adopt the way of pair programming), also need according to the situation of things, if the business has developed rapidly, or frequent change in the business, may this project waste a great deal of effort to do the CR, ensure the quality of the code, the late business change, will make this month’s efforts. Business system always puts business in the first place. If the business develops fast and the development cycle is short, excessive CR will inevitably lead to technical fatigue and lack of fuel for the team engine. That is to say, CR needs to choose an appropriate form of CR, such as pair programming or round-CR, according to the attributes of the current project and the prediction of the current business trend. Wanting BOTH A and B is often A way of setting fire to yourself.

3. Determine the checklists,

   Before CR, a CHECKLIST of CR should be developed according to the current situation of the team, that is, items that must be checked in CR, such as the standardization of codes and other aspects. Common ones are as follows:

   1. Java Development Specification
   2. Team development protocol
   3. Effective Java (see my blog)
   4. Code Book
   5. “The clean code”

   In addition, this paper presents the item of common checklist: checkmen.png

4. Control CR granularity

   In terms of code, CR should start with a service and perform CR on the current interface. As you can imagine, if a link is too long and the code is too heavy, it can be annoying, let alone giving reasonable advice. That is, the frequency of CR and the granularity of code should be controlled, and this should also be defined by the team;

5. Mental preparation

   CR is a process of coordination and communication. New recruits are eager to learn from the experience of their predecessors and get practical guidance from them through CR. No matter what role they play, they should ensure equal respect, simple and trusting attitude in terms of mentality, and do not hold critical eyes and show off mentality.

6.2 CR Process

The overall CR process is as follows:

It can be seen from the figure above that it is divided into three parts:

1. Business review

   After the developer submits the code, the business shall be reviewed according to the checklist formulated by the team. This part mainly refers to whether the check deals with some abnormal cases and whether there are omissions in the business execution process. In other words, in addition to the checklist made by the team, which is always restricted from the technical level, it is also necessary to check according to the current business process. The background color of this part is red, which means that it is the high-voltage line of the business, and business review is not directly called back. To pass before continuing;

2. Communication studies

   Ready to call technology review at first, then a thought, the code has already passed the business, that is to say, meet the basic elements of the launch, without CR, may the code has been launched, but here, take out would be to continue the discussion, as the code of design patterns, and algorithm complexity, code whether can discuss such levels as more simplified, This is one of the reasons why I want to promote CR. This part is the best opportunity for new recruits to learn from old drivers. Instead of suffering from no real case, they only learn superficial knowledge. The background color of this part is green, just as my original intention, which is open and efficient, and also the added value of CR. Of course, you need to give specific suggestions such as pseudocode or specific knowledge points, if you just talk about it, it is not much use. This section is no longer about the business, that is, the non-functional requirements of PD, but also a great place for developers to explore;

3. To fix the problem

   In the communication learning stage, there will be problems, which can be divided into two forms: 1. 2. Code refactoring or major adjustments are required.

   For the first type of simple modified code, such as forI statement lambda to write, the functional code extracted do not pollute the business method, you can immediately perform modification, optimize the code quality.

   Is another major refactorings such as introducing the strategy pattern to remove the if – else, as the caching involves optimization are modified, I think can be slow, the programmer is a professional working long hours, when it comes to this kind of change in the CR certainly takes up a lot of time, squeezed the development time, and often work overtime, will let the developer the toes, the whole team morale. In addition, in the early stage of business, the software system should be used to ensure the rapid implementation of business, that is to say, in the period of rapid business development, the code should also have tolerance, so that the rapid implementation of business to get more abundant results. This is the time to apply for lag processing, and the corresponding design-to-refactoring knowledge can also be shared as a team.

   Theoretically, this part of time investment will increase with the number of reconstruction, the accumulation of experience will be more and more rich, and the problems will be less and less, and the number of repairers applying for this part will be less and less.

The main process of CR completes the improvement of code quality and closure of problems through three aspects, as shown in the following figure:

It can be seen that A good CR must be reviewed in stages, that is to say, when the focus is on business review, it should not put forward technical opinions to the speaker. It can be recorded first and put forward in the next stage for discussion. Each stage should focus on its corresponding focus, otherwise it will appear that you say A and I say B. Arguing won’t get you anywhere.

6.3 How to measure the effect of CR

CR is considered to represent a culture of engineers, and there are various cultures in IT circles, such as geek culture, hackthon, etc. I also think CR should be seen as a culture, not an extremely mechanical tool. What culture is, it should be what people yearn for in their hearts and entrust externally. In ancient times, poets like Li Bai and Du Fu took tang poetry and song poetry as their place. Now, pilgrims walk to potala Palace three times and nine times. We always have something that is driven by the heart to be placed. But we’re used to getting high on numbers.

When Disneyland came to Shanghai, there was news on the Internet that Wanda Park was stirring up trouble in Jiangsu, Zhejiang and Shanghai, and Chinese people were used to judging the pros and cons of things based on numbers. You can find that Hong Kong Disneyland, Paris Disneyland and other places are losing money all the year round. Do you think Disney is a failure? When children are immersed in the world of Lion King and Mickey, shouldn’t we thank Disney for bringing such a wonderful and pure world to children? Then, can Disney be considered a failure according to its performance figures? Just like today, when you judge Hollywood culture, you will never judge it quantitatively based on the number of box office sales. You will only remember those characters such as Spiderman and Batman who tell everyone to be themselves. They are all heroes in the world. One might say that culture and marketization are two different things, and the two reinforce each other. Yes, but I believe marketization is just another form of culture. However, in today’s environment, we have been numb to love because of “numbers” and high, and because of such a “common disease” in society, we see the so-called engineer culture, geek culture, seem to have lost their taste.

CR should also be cultivated as a culture, more like a soft force, to the emotional ties developers bond with. ** If at the beginning, thinking to quantify, is the beginning a wrong start? The dark side of human nature that has always existed, that looks at a number and wants to glorify it, that managers look at a number and see it as a political achievement, that focuses on this cold number, that culture, how it falls on the belief of developers, that if it doesn’t, CR is already on its way to becoming a burden.

Therefore, IN my opinion, the implementation of CR must be “light” and “light” in thought, and should not be complacent because of numbers, but “heavy” in process, which is reflected in the spirit of completing the corresponding contract for each role in the collaborative activity of CR.

If you to a quantitative evaluation the effect of CR to the ground, I also think that should not be derived from the CR various data, look at the project delivery, is there a better user feedback, after to see the team have the vigor is better, look to the CR can affect the level of lateral, these are I think CR will bring the biggest change, like the article began, problems, Always just a by-product of CR!

At the very least, from the absence of CR, to the introduction of CR until the landing, isn’t that the result? As long as the beginning is a result.

In the most ideal state, CR will be the best way for mutual growth, simple and efficient, and knowledge dissemination. (The developers respect each other and love each other, so here’s a smile.)

8. Reference materials

1. What is CR

2. What is the correct posture for Code Review?

3. Four classifications of CR

4. CR的checklist

5. Case sharing of CR

6. Experience of doing CR well

7. Common problems of CR check

[8. 11 effective peer code review best practice] (kb.cnblogs.com/page/153632…).

9. How to do technology from CR

The CR was Shared

11. Goose Factory case sharing

Denver annual essay | 2018 technical way with me The campaign is under way…