探究代码审查（Code review）

Code review 是什么

对软件源代码的系统性检查，查找软件源代码质量，结构，漏洞等问题。

PS：Code review  ≈ Code inspections ≥ Code walkthroughs（代码走查）　

Code walkthroughs 相当于是 非正式的 Code review 。

怎样执行Code review

1.使用代码静态分析工具。

代码静态分析工具会辅助自己在编码进行代码审查。

以ESlint为例。

流程： （1）安装ESlint工具包。

（2）开发团队组长与成员共同制定ESlint配置文件，并共享此文件。

（3）ESlint配置文件定稿后，开发团队组长与成员共同使用ESlint配置文件，并严格按照此规范编码。

PS：代码静态分析工具帮助开发人员在本地编码时进行初步代码审查，减少在开发团队成员互检时的所需的代码审查项目，提高代码审查的效率。

2.使用版本控制工具（互检）。

考虑到学习成本与执行效率，使用版本控制工具自带轻量级的代码审查的工具是最佳选择。

以GitHub的Pull Request为例。

流程：（1）在GitHub创建好matser主分支、多个feature分支、多个feature子分支。组长设置matser主分支，feature分支只读不可写，feature子分支可读可写。

（一般不会对Matser主分支的代码审查，feature分支、feature子分支需要进行代码审查）

（2）组长安排每位团员的编码模块工作，每位团员进行编码，并且提交代码，再pull request推送到feature子分支。

（3）组长或团员对feature子分支提交的源代码进行轻量级的代码审查。

（4）组长或团员对feature子分支提交的源代码有质疑的进行代码审查，并通知负责该feature的分支的团员进行修改源代码，修复已知的问题。

（5）组长或团员确认对feature子分支提交的源代码通过代码审查之后，由组长负责将feature子分支合并到feature分支上。

（6）当各个feature分支的编码工作完成之后，再合并到Matser主分支。

（7）发布软件之前，进行一次正式的代码审查。（这个过程比较痛苦，代码过多，看情况而定。）

PS：代码审查应该注意以下几点：

        （1）是代码审查，不是浏览代码。（不禁让我想起以前小学老师在抄写汉字的作业本子写的一个大字“阅”。） 

        （2）代码要分量审查，不要大量审查。（大多数的专业人士都这么说，符合实际情况。）      

        （3）代码要互检，不要单检。（三人行必有我师，即便是圣人孔子，也要虚心请教别人。）

        （4）对有质疑的代码进行详细的注释，及时反馈提出问题与优化建议。（不要老是挑完毛病又不告诉别人怎么做，不一定所有人都很聪明，一听就懂，所以建议把优化建议说出来。）

Code review的项目

探究重构代码（Code refactoring）

Code review的优缺点

优点：提高代码质量，促进团队沟通与知识共享，发现代码的潜在漏洞。

缺点：增加工作负担，影响人际关系。

总结：代码审查是个好方法，但不一定适合所有开发团队与软件产品。

           生命周期较短的软件项目或经验不足的开发团队就不建议进行代码审查。

           代码审查建议归建议，勉强没幸福。