为什么要代码评审？

软件工程师应该像医生一样，不是把病人医好就行，还要对病人的长期健康负责。对于常见病，要快速医好很简单一下猛药，大量使用抗生素，好得飞快。但大家都知道，这明显是饮鸩止渴。医生需要有责任心和医德，软件工程师也要有相应的责任心和修养。这种修养不是“做出来”就了事，而是要到“做漂亮”这个级别，代码评审就是帮你把代码写漂亮的必经之路。

“时间不够”“需求总变”，不是拒绝评审的理由

如果业务逼得紧，让技术人员疲于奔命，那应该是需求管理和项目管理的问题。需求总变，我们更应该做代码评审，因为需求变得越快，对代码质量的要求越高，就算是一次性代码，也应该评审一下它会不会影响那些长期在用的代码。

需求评审是对团队赋能，高手阶段的软件工程师更应该积极为后辈做代码评审，这不仅是在帮助他们核查代码质量，更是一个为团队赋能的过程。

评审哪几个方面？

1.设计:代码是否经过精心设计并适合系统?

2.功能:代码是否符合开发者意图?代码对用户是否友好?

3.复杂性:代码是否可以更简洁?未来其他开发人员接手时，是否易于理解与易用?

4.测试:代码是否经过正确且设计良好的自动化测试?

5.命名:开发人员是否为变量、类、方法等选择了明确的名称?

6.注释:注释是否清晰有效?

7.风格:代码是否遵循了谷歌的代码风格?

8.文档:开发人员是否同步更新了相关文档?

特别关注：接口设计是否合适、算法复杂度是否最低、测试是否全面

评审时不要过于关注找bug

代码评审时，有比找bug更有价值的事。那就是审查更高一级的代码质量，包括代码可读性、可维护性、可重用性，程序逻辑以及对需求和设计的实现等。

Bug有专门的环节负责，不需要等到代码评审环节才做。

让人感到轻松的评审，更容易通过

通常情况下，体量比较少、改动比较少、上下紧凑的代码会更容易通过评审。因为让评审员看起来更加轻松简单。

不要等程序写完了再去评审代码

当你面对近万行代码和N多掺和在一起的功能时，会发现代码评审变得异常艰难。就好像别人已经把整个房子 盖好了，你这里挑点毛病、那里提点建议，有时候甚至直接触动地基或承重墙，需要动大手术，让别人返工，那时候麻烦就大了。