说透代码评审

　　代码如熵，不加外力很容易就会随着代码的不断堆积而发生腐烂和溃败。我们不是不知道代码问题，而是对既成事实难有改变。但是如果站在迭代的角度思考下一次升级，如何确保新的代码质量就显得很有必要，特别是你的代码需要重写的时候，我想你一定会遇到和我一样的问题，我们究竟应该如何保证我们的代码的质量？于是就有了这篇工具型的文章。

​ 以下内容架构是我摘录觉得比较重要的纬度，很多方法论借鉴了以上几篇文章思想，对代码评审的各种情况基本都谈得比较到位了，反复精读基本上就可以采用拿来主义，希望对你的团队评审有所帮助。

为什么要评审

不审查的坏处

　　代码的质量反应了我们的产品质量，产品不稳定、老是出现BUG，直接影响客户满意度和口碑。

　　同时，代码的好坏决定了未来运维的成本，如果因为一时疏忽和妥协，回头又没有及时修改，中间又出现人员变动，那么这份代码的后患是无穷的。

　　因为不规范，可读性差，对交接人来说从心态上是本能反抗的，但是又不得不改，于是就一通乱改，能贴膏药就贴膏药，能运行就可以，管他规范不规范。这样导致的后果是，代码从不规范走向更加不规范，很难想象经过5-10年持之以恒的不规范，这个产品还能活着。

　　技术债务的危害怎么形容都不为过，轻则系统局部异常，中等的会导致修改困难，严重的需要推翻重来。

　　从物理学上看，熵让我们理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展，所以规范和审查就显得弥足珍贵了。

　　从软件设计看，软件设计要关注长期变化，需要应对需求规模的膨胀。如果腐烂的代码日积月累，这些在不断流变腐烂的东西又怎能支撑起长期的变化呢！

　　做产品，不审查不足以长久。

评审的好处

　　在软件工程师日常的开发工作中，如果要挑出一项极其重要，却又很容易被忽视的工作，在我看来代码审查几乎是无可争议的第一。代码审查是一个低投入、高产出的开发活动，就个人而言，从其中学到的习惯、方法和知识，获益匪浅。

　　代码评审的作用很多，主要表现在 6 个方面。

　　好处 1，尽早发现 Bug 和设计中存在的问题。我们都知道，问题发现得越晚，修复的代价越大。代码审查把问题的发现尽量提前，自然会提高效能。

　　好处 2，提高个人工程能力。不言而喻，别人对你的代码提建议，自然能提高你的工程能力。事实上，仅仅因为知道自己的代码会被同事审查，你就会注意提高代码质量。

　　好处 3，团队知识共享。一段代码入库之后，就从个人的代码变成了团队的代码。代码审查可以帮助其他开发者了解这些代码的设计思想、实现方式等。另外，代码审查中的讨论记录还可以作为参考文档，帮助他人理解代码、查找问题。

　　好处 4，针对某个特定方面提高质量。一些比较专业的领域，比如安全、性能、UI 等，可以邀请专家进行专项审查。另外，一些核心代码或者高风险代码，也可以通过团队集体审查的方式来保证质量。

　　好处 5，统一编码风格。这，也是代码审查的一个常见功能，但最好能通过工具来实现自动化检查。

　　好处 6，社会性功用。如果你在编程，而且知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完全不同。这之间的微妙差异正是在于会不会有人将对你的代码做出反馈与评价。

评审的困境和争议

　　大多数的争议，都不是在否认代码审查的好处，而是聚焦在不进行代码审查的那些“原因” 或者 “借口”上。

1）代码评审费时费力：

　　项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？这是一个最常见的客观阻碍因素，因为 Deadline 很多时候都不是我们自己能确定和改变的。

改来改去无非是一些格式、注释、命名之类不痛不痒的问题。

2）代码审查不利于团建：

　　因为经常有程序员因为观点不同在代码审查的时候吵起来。

3）主观意愿

　　评审人用自己主观意见看待别人的代码。觉得别人的代码风格不够好，或者把个人的喜好强加到别人身上。

4）团队人员结构搭配不合理。

　　新人没经验的多，有经验的少。新人交叉评审可能效果不好，老是安排经验多的少数人帮助 Review 多数新人的代码，新人或有收获，但对高级或资深程序员又有多大裨益？

　　一个好的规则或制度&#x