Click the above link , and attention " to the star ."
Exciting content, timely push every day
Author: gem Source: http: //1t.click/aA4h
I always thought that Code Review (code review) is one of the best practices in software development, can effectively improve the overall quality of the code, the code to detect possible problems. Including such as Google, Microsoft these companies, Code Review are the basic requirements must be reviewed before the code was merged by the job.
However, for most of the software development team I observed, the Code Review seriously do very little, some a mere formality, and some may simply not part of the Code Review, code quality depends only on the post-test. Some teams also want to do a code review, but do not know how to do better.
Online articles on how to make the Code Review has a lot, and here I combine some of their own experience, but also compiled a summary of the best practices of the Code Review, Code Review hoping to do something to help.
# Code Review What are the benefits?
Many teams or individuals do Code Review, the root cause still do not think this is a meaningful thing, do not think there is any good. This problem from several angles.
First, the team knowledge sharing angle
A development team, the level of high and low, everyone focused on the field there are also different. How to help newcomers make a high level of growth? How to let everyone focus on beyond their own field of knowledge remains understand? How can someone else take over after leaving quickly? These are the team managers concerns.
The code review, is a good way of sharing knowledge. Through code review, experts pointed out that the novice can code directly, the novice can immediately learn from feedback to the master of good practice, to get faster growth; through code review, the front also can go to learn the back-end code, do the functional modules a function may be to understand the module B.
Some may feel that the novice master code review a waste of time, and he did not harvest. In fact, new growth, and can be more expert help share the onerous task; take the time to review the code, it is less help newcomers fill the hole backside of time; good communication skills, ability to find the problem and help others growth, technology transfer are essential to a higher level of management or technical skills, the ability to practice effectively in these areas through code review.
Then the angle code quality
The reality of project manpower shortage schedule is always tight, so compressed is often automated testing and code review, the results of the impact code quality, technical debt owed, finally had to redouble repaid.
It was also the hope of manual testing and development, but for code quality, many questions to pass the test is to test it out, and only through code review. For example, the readability of code maintainability, such as the structure of the code, such as an infinite loop until certain conditions are triggered, logic arithmetic error, there are some loopholes in security and easier detection and prevention through code review.
Some people feel that they do not need another job level of code review. For the master, to let other people review your code, you can let other people to learn good practice; let other people review the same time, to others to explain their code, also equal to own their own code of conduct a review . This is actually just like we do the math at school, like, really could get a high score is often done after those will be carefully examined.
There are teams normative point of view
Each team has its own code standards, have their own development standards-based architecture, but over time, you will find a lot of non-compliance with the code specifications appear in the code, there are many to bypass the architectural design code. For example, difficult to understand and not standardized naming, such as three-tier architecture inside the UI layer to bypass the business logic directly call the data access layer code.
If the code is correct violate norms of late, and then back to the high cost of the modification, and the team's specifications will slowly useless.
Through code review, allows you to quickly discover and correct these problems and ensure the implementation of team norms.
About the benefits of code review, there are many, do not list them. Still hope to recognize the Code Review and writing automated tests, are part of Misfortune work cut firewood, putting a little bit of time on it, the future will gain code quality, it will save overall development time.
# How to do?
Now many people are already aware of the importance of the Code Review, just do not know how to practice, do not know how to be good practice Code Review.
Code Review as the development process rather than mandatory option
In the long ago, I tried the code review process as part of the code, but only an option, not the code Code Review can also be incorporated into the master. The result is to think of it will do it Code Review, to check the time has been too much code changes, it is very difficult to review, even if additional review of the problem, it is difficult to modify.
We now review the code of the development process as a necessary option, each time developing new features or fix Bug, to open a new branch, branches to be merged into master there are two necessary conditions:
1, all through automated testing
2, at least one person through the Code Review, if it is new to the PR, there must be a senior programmer by Code Review
Image Source:
How to Do Code Reviews Like a Human
In this way the Code Review as a necessary option after the development process, it is good to ensure that the code has been Code Review prior to the merger. And requires code review prior to this consolidation process, the benefits are obvious:
* Because each time to do code review prior to the merger, which is generally the amount of code review will not be much for the censors, it will not be much pressure
* If problems are found in the Code Review, the reviewer want the code can be incorporated as soon as possible, will actively make changes to review the issue out, and will not review the results too inconsistent
If you find it difficult to implement Code Review, Code Review may wish to try to taste becomes a necessary option your development process.
Code Review to become a development culture and not just a system
Code Review after the positive as mandatory development process, it does not mean good Code Review can be carried out, because the implementation of the Code Review, depending on the reviewer's review very carefully the most extent, and the reviewers fit, both are indispensable!
If just as a flow system, then there may be a mere formality. The end result is that there seems Code Review, but no one seriously review, just look through it, or find the problem is not willing to modify.
真要把Code Review这件事做好，必须让Code Review变成团队的一种文化，开发人员从心底接受这件事，并认真执行这件事。
要形成这样的文化，不那么容易，也没有想象的那么难，比如这些方面可以参考：
首先，得让开发人员认识到Code Review这件事为自己、为团队带来的好处
然后，得要有几个人做好表率作用，榜样的力量很重要
还有，对于管理者来说，你激励什么，往往就会得到什么
最后，像写自动化测试一样，把Code Review要作为开发任务的一部分，给审查者和被审查者都留出专门的时间去做这件事，不能光想着马儿跑得快又舍不得给马儿吃草
如何形成这样的文化，有心的话，还有很多方法可以尝试。只有真正让大家都认同和践行，才可能去做好Code Review这件事。
# 一些Code Review的经验技巧
在做好Code Review这件事上，还有一些经验技巧可以参考。
选什么工具辅助做CODE REVIEW？
现在很多源代码管理工具都自带Code Review工具，典型的像Github、Gitlab、微软的Azure DevOps，尤其是像Gitlab，还可以自己在本地搭建环境，根据自己的需要灵活配置。
配合什么样的开发流程比较好？
像Github Flow这样基于分支开发的流程是特别适合搭配Code Review的。其实不管什么样的开发流程，关键点在于代码合并到master（主干）之前，要先做Code Review。
真遇到紧急情况，来不及代码审查怎么办？
虽然原则上，必须要Code Review才能合并，但有时候确实会存在一些紧急情况，比如说线上故障补丁，而又没有其他人在线，那么这种情况下，最好是在任务管理系统中，创建一个Ticket，用来后续跟踪，确保后续补上Code Review，并对Code Review结果有后续的代码更新。
先设计再编码
有些新人发现自己的代码提交PR（Pull Request）后，会收到一堆的Code Review意见，必须要做大量的改动。这多半是因为在开始做之前，没有做好设计，做出来后才发现问题很多。
建议在做一个新功能之前，写一个简单的设计文档，表达清楚自己的设计思路，找资深的先帮你做一下设计的审查，发现设计上的问题。设计上没问题了，再着手开发，那么到Review的时候，相对问题就会少很多。
代码在提交CODE REVIEW之前，作者要自己先REVIEW和测试一遍
我在做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至自己都没有测试过，就等着别人Code Review和测试帮助发现问题。这种依赖心理无论是对自己还是对团队都是很不负责任的。
一个好的开发人员，代码在提交Code Review之前，肯定是要自己先Review一遍，把该写的自动化测试代码写上，自己把基本的测试用例跑一遍的。
我对于团队提交的PR，有个要求就是要在PR的描述中增加截图或者录屏，就是为了通过截图或者录屏，确保提交PR的人自己是先测试过的。这也是一个有效的辅助手段。
PR要小
在做Code Review的时候，如果有大量的文件修改，那么Review起来是很困难的，但如果PR比较小，相对就比较容易Review，也容易发现代码中可能存在的问题。
所以在提交PR时，PR要小，如果是比较大的改动，那么最好分批提交，以减轻审查者的压力。
对评论进行分级
在做Code Review时，需要针对审查出有问题的代码行添加评论，如果只是评论，有时候对于被审查者比较难甄别评论所代表的含义，是不是必须要修改。
建议可以对Review的评论进行分级，不同级别的结果可以打上不同的Tag，比如说：
1、[blocker]: 在评论前面加上一个blocker标记，表示这个代码行的问题必须要修改
2、[optional]：在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改
3, [question]: add a [question] mark in front of the comments expressed on this line of code does not understand that there are issues that need to ask, who needs to be examined for clarification question reply
Graded like this can help be reviewed by an intuitive understanding of the results of Review, Review improving efficiency.
Comments Be friendly, avoid negative words; there is clear, the problem face to face communication
Although the Code Review comments are the main means of communication, but do not be too dependent on, sometimes face to face communication more efficient, but also easy to remove misunderstandings.
In addition civilized language, do not use some of the negative words.
# to sum up
Code Review is a very good development practice, if you have not started, might gradually practice them; if you have done a bad effect, may wish to control what, to see if the Code Review process as a development rather than a mandatory option ? Code Review did not have to become a development culture and not just a system?
Recommended Reading
(Click on the title to jump to read)
5.
7.
8.
9.
10.
Press two-dimensional code concern recognition