2019独角兽企业重金招聘Python工程师标准>>> 
代码审查（英语：Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结伴编程、非正式的看过整个代码，或是正式的软件检查。
代码审查的目的（对程序）：
- 最佳实践：为了更有效、少出错或更高雅的搞定任务
- 错误探测：发现逻辑或过渡期的错误(过渡期的错误:临时解决方案带来的错误)
- 增强健壮性：定位并修复缺陷，比如跨域脚本、内存泄漏等隐患。提升代码安全性。即使有些在当前是可以忽略的。墨菲定理
- 发现恶意逻辑：寻找那些看起来无关紧要、有问题的、或者是很奇怪的代码段。其目的是发现后门、特洛伊木马和定时炸弹。我说经常被忽视，因为恶意软件和恶意的意图可能会给一些开发者造成太大的戏剧性。或者某些小把戏，也就是“自负”，比如虾米程序员diss vip用户，写代码的时候就是为了好玩，希望引起别人的关心。但其实，不会给自己带来任何实际的好处。另一方面，有些代码，不明白是什么意思，担心删了之后会有影响，那么我建议重构成大家看的懂的代码。
上述目的中，只有恶意逻辑是必须需要人为介入的。
代码审查的目的（对开发人员）：
- Code reviews 中，可以通过大家的建议增进代码的质量。
- Code reviews 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
- Code reviews 也鼓励程序员们相互学习对方的长处和优点。
- Code reviews 也可以被用来确认自己的设计和实现是清楚和简单的。
因此 代码审查和测试是两码事，代码审查能减少bug率，但不应该承担发现代码错误的职责。
代码审查包含如下部分：
- Who ~ 涉及的人
- When ~ 执行的时间
- Why ~ 动机是最佳实践, 错误探测, 增强健壮性, 发现恶意代码或兼容性
- Where ~ 地点
- What ~ 程序版本，类名，方法名,代码行数等更具体的代码范围
- Result ~ 暴露出的结果
代码审查的分类：
- 正式审查： 有审慎及仔细的流程，由多位参与者分阶段进行。正式的代码审查是传统审查代码的方式，由软件开发者参加一连串的会议，一行一行的审查代码，一般会使用打印好的原行码。正式的代码审查可以彻底的找到程序中的缺陷，但需要投入许多的资源。
- 结伴编程 两个程序员在一个计算机上共同工作，一个输入程序，另一个工程师审查他所输入的程序，结对编程是在极限编程中常见的开发方式。
- 轻量级代码审查 需要投入的资源比正式的代码审查要少，一般会是在正常软件开发流程中同时进行，有时也会将结对编程视为轻量型代码审查的一种。
轻量级评审通常作为正常开发过程的一部分进行。
- 一个在写，一个在看
- 代码签入后，邮件通知评审员
- 结伴编程，A写B看，几个功能之后，角色互换，B写A看。
- 结合工具。作者和评审员使用工具。
卡珀斯·琼斯（Capers Jones）分析了超过12,000个软件开发项目，其中使用正式代码审查的项目，发现潜在缺陷率约在60-65%之间，若是非正式的代码审查，发现潜在缺陷率不到50%。大部份的测试，发现的潜在缺陷率会在30%左右。
对于一些关键的软件（例如安全关键系统的嵌入式软件），一般的代码审查速度约是一小时150行程序码，一小时审查数百行程序码的审查速度太快，可能无法找到程序中的问题。代码审查一般可以找到及移除约65%的错误，最高可以到85%。
也有研究针对代码审查找到的缺陷类型进行分析。代码审查找到的缺陷中，有75%是和计算机安全隐患有关。对于产品生命周期很长的软件公司而言，代码审查是很有效的工具。
wiki的结论：轻量级评审揭示了与正式评审一样多的缺陷。但速度更快、成本更低。
特别注意的几个误区：
- 审查者和被审查者不存在能力高低问题。A发现B的bug，并不代表A编码能力比B强。代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。
- 代码审查本身可以提高开发者的能力：被审查者从自身犯过的错误中学习，从他人的思路中学习；审查者从审查的思考过程中学习，从被审查者好的设计中学习。
- 代码审查一般不涉及奖惩机制，即便有也是对审查者和被审查者同时的奖励或处罚，也就是说两者要同时对交付负责。是非零和游戏，不是原配斗小三。在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。
如果在审查中发现问题，务必由原作者进行确认。这样做有两个目的：
- 确认问题确实存在，保证问题被解决
- 让原作者了解问题和不足，帮助其成长
笔者工作中遇到过两种人：
- 代码写的很简单，一眼看上去就不会有问题。
- 代码写的很复杂，不能一眼看出其中的问题。然后就不明觉厉感觉很厉害。
实战：
- 经常进行Code Review，小步快跑代替最终一次性审查。
先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review。当然，最佳的practice是，每次Review的业务逻辑代码应该在1000行以内，时间不能超过一部电影的时间——1.5小时（因为据说那个一个正常人的膀胱可以容纳尿液的最长限度）
- Code Review不要太正式，而且要短
不正式的Code Review会让你和评审者放轻松，人只有放松了，才会表现得很真实真诚。记住Review只不过是一种形式，而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议和意见，那才是最实在的。不然，作者和评审者的关系就会变成小偷和警察的关系。
- 尽可能的让不同的人Reivew你的代码，3人左右。
不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度，有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度。当然，不要太多了，人多嘴杂反而适得其反，基本上来说，不要超过3个人，这是因为，这是一个可以围在一起讨论的最大人员尺寸。 这样做的优点：
-
从不同的方向评审代码总是好的。
-
会有更多的人帮你在日后维护你的代码。
-
这也是一个增加团队凝聚力的方法。
-
保持积极的正面的态度，别自负。你会被review，也会review别人的代码的。大家相互配合，共同提高。出来混，总是要还的。
一般是闭环式审查，如4个人的子团队，审查关系为A --> B --> C --> D --> A（B审查A，C审查B，D审查C，A审查D）。当然，要适成员能力做到高低的有效穿插。那么让初级工程师审查高级工程师的代码是否有问题呢，能发现BUG么？首先，肯定能发现BUG，只是多少和频率的问题；其次，即便初级工程师发现不了高级工程师的BUG，在审查高级工程师的代码时也能学习到好的思路和业务知识，这也是很有意义的，间接起到培训的作用了。
- 学会享受Code Reivew，当review被大家所接受，有正向反馈。团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。
审查粒度：
以future和task任务为单元做review较容易实施，大规模review可以在重大改进时单独发起。同时，把review结合到任务工作流里也是不错的实践。如：start --> 设计 --> 开发 --> code review --> 测试 --> 产品确认 --> end。 一个review单元的时间应控制在10~20分钟。如果超出这个时间，可能是如下几个原因：
- 如果20分钟一个reviewer还看不懂一个任务的代码，那么这个代码本身就存在问题，太复杂了；
- reviewer不懂业务，那么开发者就需要向reviewer讲解下了，当然不需讲解就能看懂的代码自然是更好了；
- 任务太大，代码太多，那么这个任务应该拆分，分阶段交付产出。
成功案例：我们是怎么做Code Review的
参考：
- 其他参考资料1
- 其他参考资料2
- Java Code Review
- 从CODE REVIEW 谈如何做技术
- CODE REVIEW中的几个提示
- 加班与效率
- Code Review 程序员的寄望与哀伤