代码评审是一些人提交一些代码片段，供另外一些人审阅的流程。在数栈，我们都是通过代码评审来保证代码和产品的质量。这篇文档是对数栈评审流程和策略的权威描述
- 提升代码质量，代码可读性，可维护性, 发现潜在缺陷&风险，避免一些低级的 bug 在代码部署到测试环境才被发现
- 从团队规范角度，由于新成员的加入提高了团队编码风格的差异性，保证团队规范的执行
- 团队成员交叉代码评审无统一评审标准；其次有些他人写的业务逻辑，在交叉维护时，需要花更多的时间上手
- 促进人才成长，对新成员的代码质量和成长负责，提升整个团队的技术实力
- 知识传递，人员备份，保证有人离职后其他人能快速接手
- 在不是很了解现有项目的基础上，实现的新功能代码会产生冗余
一个开发团队中，水平有高有低，每个人侧重的领域也有不同。怎么让高水平的帮助新人成长？怎么让大家都对自己侧重领域之外的知识保持了解？怎么能有人离职后其他人能快速接手？这些都是团队管理者关心的问题。而代码审查，就是一个很好的知识共享的方式。 通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长，尤其针对同一项目多人负责的情况，便于团队成员相互学习不同模块的代码。
代码质量可以从两个维度来理解，一是可读性，一是缺陷情况，谷歌最早引入代码评审的初衷是保障代码易读性，代码也是一种资产，具有“流通性”，通常会面临 3～5 年的迭代维护，期间会面临人员更替，其他人参考引用的情况，在基于众多的技术手段及流程规范中，相较于其他基于结果进行验证的质量保证的手段，Code Review 的关注点更加广泛全面，能够发现程序逻辑以外的设计，性能，规范等多方面的问题。
每个团队都有自己的代码规范，有自己的基于架构设计的开发规范，然而时间一长，就会发现代码中出现很多不遵守代码规范的情况，有很多绕过架构设计的代码。如果这些违反规范的代码被纠正的晚了，后面再要修改就成本很高了，而且团队的规范也会慢慢的形同虚设。 通过代码审查，就可以及时的去发现和纠正这些问题，保证团队规范的执行
如何提升产品业务代码质量，促进一线研发人员的成长，一直是一个避不开的话题，我们一线的技术团队，按照层级呈现金字塔型，如果团队核心骨干人员能参与到团队日常的架构评审，设计评审及代码评审，一定可以切切实实的帮助到其他研发人员的成长，不论是新人的融入还是处于瓶颈期的开发人员。
虽然我们都渴望工程师能够热爱自己所从事的工作和技术，但这只是我们期望的结果，但是可以通过点滴的代码评审培养工程师对代码关注和思考多了也是一个长期受益的事情，
- 热爱：对于一线工程师来说，每天产出的是一行一行的代码，但是如果有人（非机器）能对自己深思熟虑并且精心雕琢过的代码给予正向的激励，那其实是会提升工程师对代码的热爱的
- 思考：其次也会鼓励工程师主动式思考，比如怎么写效率高且更具备可扩展性，换个角度想一一下，假如你知道你写的每一行代码，每一次提交，都会被大家看到，都会有人审核，那么其实在写的时候，工程师就会多想一下，无形之中通过流程促使工程师在日常产品开发中养成了主动思考的习惯
- 资深的工程师偏少
- 有单独负责项目的情况
- 执行力不足
- 缺少明确的 CheckList
不同团队对代码评审有着不同理解，我们需要就实现我们的代码评审先达成共识，并且以下所有的规则都是围绕这份共识设计
- 让代码评审回归 编码设计&易读&缺陷等, 软件质量本身是系统治理，不期望代码评审能解决所有问题
- 代码评审对软件质量保障有长远且显著的正面效果，不期望和评价短期效果，是一个长期坚持能看到效果的代码管理手段
- 把代码评审作为开发流程的必选项而不是可选项
- 把代码评审变成一种开发文化而不仅仅是一种制度