Use 7 tricks in code review to successfully establish your opposition alliance

In software development , Code review is a key process .

A team , Code review is well done , It can greatly improve the overall delivery quality of the team , At the same time, members of the team can also improve their abilities .

Another aspect , If the review goes astray , Code review may become the scene of a large stampede , Connect with each other , Destroy trust, etc .

Here's how to screw up a code review , To set up enemies for you 7 Tricks ：

1、 Code style feedback

In code review , Initiate mutual connection with unsuspecting colleagues , The best move is ： Constantly point out that it does not conform to the coding specification .

 

Most companies have documentation of coding specifications , Study and make good use of it . Then start asking for modifications that are not explicitly mentioned . If nothing is mentioned in the code specification , Then this is a perfect opportunity , You can ask for meaningless modifications , This will bring a lot of meaningless work to your goal of interconnection , for example ：

• Have you given the correct type prompt to the methods in the unit test class ？
• Method is not added void Is the logo of ？
• Is the naming of variables too verbose ？
• wait .

Use coding specifications , Come and torture your companions constantly .

2、 Ask for meaningless changes

The first step is annoying , But it won't make your enemies resent . Your continued efforts , Then there are meaningless change requests .

If there are two ways to do something , Ask them to modify the code in your way , Don't accept the reasons that are unfavorable to you but beneficial to him .

You need to write feedback at length , To defend your so-called right .

If you don't want to write too much explanatory stuff , Then you can also use such words , Make them feel unreasonable ：

I don't know why you are so hard to accept my request , It is right to do so , It's for you , Please follow what I said , thank you .

Let your colleagues , Spend a lot of time every day rewriting code that works well , Isn't it cool .

3、 A long delay

Don't worry when giving review feedback . Receive review request , stay 24 Hours , even to the extent that 48 When I was a child , Let's do the review again . When you receive a pressing challenge , Just claim to be busy with other things .

The goal is to make his PR stale . Pulling branches that fail to close in time will be considered technical debt , Need to pay extra work to do maintenance . This is a very boring job . So delay the duration of each branch as long as possible , To increase the version merging process of your target colleagues , The risk and time to resolve the conflict .

If your interconnection goal , Not before the branch of each version is pulled , Handled 2-3 Secondary merge conflicts , Then your speed is too fast , There is a lot of room for progress .

4、 Ask for more bug

Request to add changes , It is a good way to increase the workload . And ask for changes and bring bug The negative impact of , This is also a way to increase the workload .

Your mutual enemies , One side needs to work hard to make changes , Then after the change, I found a new bug, On the one hand, you have to spend time repairing the new bug, Is there a sense of achievement .

5、 There are only code specification changes in the review request

You let your enemy review every change , Should at least include 50% The above non critical functions 、 Unnecessary code style adjustments .

 

Try not to ask for clarification of key changes , Let your enemies guess for themselves , Let them waste time blindly dealing with your review .

6、 Create a wide range of reviews

When reviewing dozens of lines of code , It's very easy . But what you want is not easy and simple , Instead, I hope your enemies will feel afraid when they receive your review request ： Let your review , Include at least 10 A few papers ,1000 Line the above code .

 

For such branch requests , It also needs to be handled quickly , They are technical debt , You can merge and solve code conflicts by yourself . So we should constantly harass and urge everyone , To quickly complete the merging of your branches .

meanwhile , And don't accept anyone's feedback about your slow response to the branch version , Let them know the importance of your version .

7、 Ignore others' feedback

During the code review , Always emphasize this ： Ignore others' feedback , Because they're taking revenge on you .

 

In code review , The best way to avoid any negative feedback : Ignore all feedback .

Has anyone given feedback that needs to be changed ？ Ignore him , Find a relationship to get the version merged , Instead of trying to repair it .

Don't like anyone using effective feedback to increase your workload , Let them be like drops of water on the back of ducks , Slide down from your branch version .

Last

Let the above actions , Keep repeating , repeat , Repeat again .

For months , Your enemies will regret their contempt for you .

If you want your enemies to like code , What you shouldn't do ：

• Automate your code style , So that it can be processed automatically ;
• When there is only a better solution than the existing version , Will arrange the change request ;
• Quickly pull the request accordingly , And arrange time for code review every day ;
• When a change is requested , Ensure that all changes are tested ;
• But after you use the new coding style , Schedule separate requests ;
• Create small and frequent pull requests for code reviews ;
• Respond to all feedback , Or agree to , Or state the reason why you disagree .

original text ：

 

http://repohealth.io/blog/code-review-how-to-make-enemies/