Original: Monkey World (wechat official ID: Cxytiandi), welcome to share, please reserve the source.

CodeReview I believe that many companies have such a process at present, the key is that it is difficult to say whether this process is useful. It mainly depends on your understanding of CR and whether you really implement CR and pay attention to the hidden value points brought by CR.

I’ve recently been asked about CR by people who are starting to do CR and want to know if there are best practices. So today to talk to you about CR this topic, WHAT I said is not necessarily right, just for reference.

To be honest, I don’t think there are any best practices for CR. Because every company or every team has a different way of doing CR, the only way to really do CR well is to do it first, and then slowly refine the CR method that suits your team.

1. The purpose of the CR

There must be a reason for doing CR. What is the purpose of CR? It could be a process, it could be improving the code, it could be everybody’s doing it and I’m doing it. I think the purpose has the following several, please look down.

1.1 Stable Production

When you think about it, each iteration is tested, and then released into production. The most likely problem is that your new functionality changes to the old logic, assuming the testing doesn’t show up. This will affect the stability of production once it is online, so the most important purpose of CR is to stabilize production.

We need to CR the code to see if it changes to the old code, if it affects the old logic, if it adds switches, if it backstops. Because there will always be new people in a team who are not very familiar with the business, it is very likely to correct mistakes, and it is very likely to leave a hidden Bug, which requires CR to focus on.

It’s ok to go live, but it must not affect the old version, and it must not fail, otherwise your performance will be cool. You say you don’t want to do CR, will your colleagues allow it? Boy, please do CR obediently!

1.2 Indirect cultivation of BACKUP

Be sure to nurture backup when managing your team, because you never know who will leave the team next. The liquidity of Internet company is still quite big, because only job-hopping can raise salary ah, I spoke the words in everyone’s heart again.

In addition, the owner can be designated as the owner of a certain piece of business. During development, the owner leads other people to develop the business together. In fact, there is backup in this process, because the business of this piece of business is no longer known to a certain person.

Also cultivate backup off the table, where CR is a good opportunity. CR can let more people familiar with these businesses, but the way must be careful, do not just look at the code, which is not involved in the development of a very confused state. You can have a general look at PRD before CR, and then ask CR staff not to Review lines of code when explaining, but to tell you what requirements and functions you have done in this iteration. The corresponding code is the current CR code. In this way, people can both understand the business and do CR, killing two birds with one stone.

Of course, you may say that even if you do CR the way you say it, it may not be familiar to others. This is of course, the most familiar or write code that person! But we gave other people a sense of where the code was if the person writing the code left and there was a Bug to fix. I remember CR and I made some suggestions. It’s better than nothing, isn’t it?

1.3 Improve code quality

Purely from the technical level, the purpose of CR is to let everyone to find fault, nitpicking. Everyone’s experience is different, and everyone’s way of thinking is also different. Often you think this is the easiest way to write, while others may have a simpler way to achieve it.

In the process of CR, people will put forward their opinions, implementation ideas, whether the code is written succinctly, whether there is an open source framework that can directly implement a certain function, whether the design pattern can be optimized to improve scalability. Domain modeling is reasonable, module division is in place and so on a series of problems.

For a newcomer, it is very helpful for him to get a lot of advice from experienced colleagues in CR. It also keeps the quality of your project code at a high level. This is the purpose for us to do CR. Of course, the reality may be very cruel. Many projects will be in a mess at the end, and the code is too bloated. This is very common, especially in startups.

2. The CR

I’ve said a few things about what I think CR is for, so how do you do CR? What are the common ways? Let’s go on.

2.1 Gitlab

Before using Gitlab to do CR, it is generally to make an MR request first, and then do CR for this request. All the changes in this MR request are the points we need CR. If there is anything that needs to be modified, remarks can be added in the corresponding code. After CR is finished, they can be modified according to the remarks at that time.

2.2 Development Tools

It is also very convenient to do CR directly in our development tools. The advantage is that you can see all the code of the whole function, which means that you can follow the business process to explain the corresponding code. Then it’s also very clear what your changes are and what’s old code.

3. The timing of the CR

3.1 Before the test

Before the test is the best time for CR, at this time we need to improve the CR directly after the change. Then when we test it, we have changed the code, perhaps reducing a lot of bugs, and measuring it as smooth as silk.

What are the effects of CR before the test? It is our development time. We should have put forward the test immediately after the development is finished, but CR should be carried out before the test. Unless your development progress is advanced, how to do CR before the development is finished?

In fact, this is the process we mentioned above. By integrating CR into the r&d process, one day’s buffer can be set aside for CR when evaluating the time. For example, if the test is to be carried out on 11th, CR will be on 10th and development will be completed on 9th.

3.2 After the test

It’s really bad to do a CR after a test, and we did it before, and we immediately changed it to before a test. Because there are points that need to be modified during the process, and then these points may have been tested. Then you change it again, resulting in new bugs and increased testing effort.

There was even one CR where it was changed on the spot, and then submitted it without noticing, without synchronizing with the test. The next day the production environment was bugged directly, so make sure you don’t do CR after beta and close to launch.

For another example, there was a team that always liked to do CR on launch day, and testing has returned to the whole thing, and they’re still working on CR. Of course I don’t know if there were any changes to the code, because it’s not a team, but the most serious thing is that there will be bugs in the return that need to be fixed. And they couldn’t find anyone to fix it, they went to CR, and no one paid attention. As a result, we have to be late every time we go online.

3.3 After Going Online

What’s the point of CR after you go live? The code has been released, at this time CR out of the problem to change or not to change? Will it change in the next iteration? Is there a regression after the next iteration? Is the test willing?

As the saying goes, don’t put off what you can do today until tomorrow. Things in the current iteration should be solved in the current iteration, otherwise they will pile up.

conclusion

For CR, we still need to embrace positively, to land, to practice. It may take a while, but the payoff is good. The project’s code quality improved, the team’s technical atmosphere improved, there were significantly fewer bugs online, and people were more familiar with the business.

If you don’t have a CR, please send this article to your boss, just capricious.

If it works for you, just forward it!

About the author: Yin Jihuan, a simple technology lover, the author of Spring Cloud Micro-service – Full stack Technology and Case Analysis, Spring Cloud Micro-service Introduction combat and Progress, the founder of the public account Monkey World.