7 posts
IBM、AT&T、HP 和 Microsoft 的多项研究均证实，非正式代码审查大约能发现四分之一的缺陷。以下是数据实际说明的内容、该比例偏低的原因以及解决方法。
非正式代码审查能够发现被审代码中 15% 到 30% 的缺陷。这不是观点，而是在四十年、多家公司、数十项研究中反复验证的结论。 迈克尔·费根于 1976 年在 IBM 记录了这一数据。1987 年 AT&T 贝尔实验室的研究发现了 20%。1996 年惠普的研究发现了 25%。2013…
大多数审查检查清单都是复制粘贴的良好愿望列表。Fagan inspection风格的结构化检查清单基于实际缺陷数据构建，针对特定工件类型，并在个人准备阶段使用。以下是如何构建一个有效的检查清单。
如果你的团队有一份代码审查检查清单，它很有可能躺在没人打开的维基页面上。上面大概写着"check for off-by-one errors"和"verify error handling"之类的话。这些话都是对的。但也过于笼统，不足以改变行为。 一份告诉你"check for…
费根审查需要四到六个人、两小时才能审完250行代码。大语言模型可以通过承担准备工作和检查清单的执行来削减这部分成本，但它无法取代人类角色去发现最昂贵的缺陷。
一次完整的费根审查需要一名主持人、一名朗读员、两到四名审查员，以及作者本人。团队以每小时125行的速度，花费两小时审查大约250行代码。这意味着一次小小的改动就要消耗八到十二人时。 大语言模型可以在不到一秒内读完250行代码。它可以执行检查清单、标记可疑模式，并在任何人打开文件之前就生成一份结构化的缺陷记录。…
Michael Fagan 在 IBM 设计的结构化审查流程，能在代码进入编译器之前捕获几乎全部缺陷。但它也消耗了项目总工时的15%–20%。本文解释软件史上最有效的审查方法为何消失，以及团队究竟失去了什么。
1976年，Michael Fagan 在 IBM Systems Journal 上发表了一篇论文，描述了一种审查流程，其有效性使之成为软件质量的金标准。Fagan Inspections 在尚未运行任何测试之前，就能捕获全部缺陷的60%到90%。NASA…
即使是高级工程师，在非结构化审查中也只能发现一小部分缺陷。Michael Fagan 在IBM的研究揭示了原因，并构建了结构化审查流程来解决这一问题。
两位高级工程师审查同一份拉取请求。一位标记了缺失的空值检查。另一位发现了清理路径中的竞态条件。两人都没有发现全部问题。 如果你只指派了一位审查员，那么其中一个缺陷就会被发布上线。这不是技能差距。这是人类注意力的可预测特性，而 Michael Fagan 于1976年在IBM记录了这一现象。 Fagan…
非正式的代码审查只能发现15%到30%的缺陷。Fagan Inspection是一种有50年历史的结构化流程，持续报告60%到90%的缺陷移除率。以下是它的工作原理、团队回避它的原因，以及如何运行轻量级版本。
大多数代码审查只能发现本应找到的缺陷的15%到30%。这不是猜测。IBM在20世纪70年代就测量过，AT&T、惠普和微软的研究也在数十年间反复确认了这一范围。 非正式审查成本低廉、异步进行、 socially…
当 AI 能从规格生成实现、测试和 contracts 时，人类最有杠杆效应的工作会前移到上游。最需要被严格审视的，是规格本身。
如果你已经用 AI 连续交付了几周以上，你大概认识这种感觉。 你打开一个 PR。代码够干净，命名也还过得去，测试也有。表面上看不出哪里明显坏了。可你还是会觉得哪里不太对。 也许 boundary 有点发虚。也许 contract 只是被默认存在，却没有被明确写出来。也许 happy path…