45代码评审寄望与哀伤.pdfVIP

2018/11/14 极客时间 | 程序员进阶攻略 代码评审的初衷是提高代码质量，在代码进入生产环境前经过同行评审来发现缺陷，降低损失概 率。这一点程序员都好理解，提前的代码评审就像雷达扫描我们重点关注的代码领地，以期发现 或明显或隐藏的危险因素。 漫画《火影忍者》里有一种忍术技能：白眼，这种技能有近 360° 的观察范围。程序员在写程序 时力求思考全面，不留死角或盲点，但实际死角或盲点总是存在的。随着我们经历和经验的成 长，思考和认识得越发全面（越发接近 360°），拥有了近乎 “白眼” 的能力，但即使是像 “白眼” 一样，也依然会存在盲点。 正如世界上没有两片完全一样的树叶，也许也不会有两个认知视角完全重叠的人，这样相互进行 代码评审也就弥补了个人单一视角和认知思考的盲点问题。除此之外，代码评审还有一个社会性 功用，如果你在编程，而且知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完 全不同。这之间的微妙差异正是在于会不会有人将对你的代码做出反馈与评价。 代码评审的编程实践正是基于这样的感性认知，影响你的编码心理，并试图通过群体视角来找出 个体认知盲点区域的隐患或 Bug，但到底这样的做法能降低多少出现 Bug 的概率呢？ 理性分析 有人对代码评审的作用进行了更理性且量化的分析，结论如下（来自 百科）： 卡珀斯·琼斯（Capers Jones）分析了超过 12,000 个软件开发项目，其中使用正 式代码审查的项目，发现潜在缺陷率约在 60%～65% 之间；若是非正式的代码审 查，发现潜在缺陷率不到 50%；而大部分的测试，发现的潜在缺陷率会在 30% 左右。 一般的代码审查速度约是一小时 150 行，对于一些关键的软件，一小时数百行代 码的审查速度太快，可能无法找到程序中的问题。对于产品生命周期很长的软件公 司而言，代码审查是很有效的工具。 从如上的实验分析结论来看，代码评审对于发现潜在缺陷很有用，相比测试能发现的缺陷率高一 倍，但也需要投入巨大的时间成本 —— 一小时审查 150 行代码，再快就不利于发现潜在缺陷 了，而且更适用于长生命周期的产品。 所以，下面这个现象就容易理解了。我发现在同一家公司做代码评审较多的都是研发通用底层技 术产品或中间件的团队，而做业务开发的团队则较少做代码评审。两者对比，底层技术产品或中 间件的需求较稳定，且生命周期长；而业务项目，特别是尝试性的创新业务，需求不稳定，时间 要求紧迫，并且其生命周期还可能是昙花一现。 多种困境 /column/article/68215 2/6 2018/11/14 极客时间 | 程序员进阶攻略 从感性和理性两个角度认知和分析了代码评审的好处，但其适用的场景和花费的成本代价也需要 去平衡。除了这点，如果把代码评审作为一个必要环节引入到研发流程中，也许还有一些关于如 何实施代码评审的困境。 困境一，项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？这是 一个最常见的客观阻碍因素，因为 Deadline 很多时候都不是我们自己能确定和改变的。 困境二，即使强制推行下去，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了 评审的初衷和意义。 困境三，团队人员结构搭配不合理，新人没经验的多，有经验的少。新人交叉评审可能效果不 好，而老是安排经验多的少数人帮助 Review 多数新人的代码，新人或有收获，但对高级或资深 程序员又有多大裨益？一个好的规则或制度，总是需要既符合多方参与者的个体利益又能满足组 织或团队的共同利益，这样的规则或制度才能更顺畅、有效地实施和运转。 困境四，有人就是不喜欢别人 Review 他的代码，他会感觉是在找茬。比如，团队中存在一些自 信超强大的程序员，觉得自己写的代码绝对没问题，不需要别人来给他 Review。 以上种种，仅仅是我过去经历的一些执行代码评审时面临的困境与障碍，我们需要找到一条路径 来绕过或破除这样的障碍与困境。 参考路径 在