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。程式碼夠乾淨。命名還不錯。測試也有。看起來沒有任何明顯壞掉的地方。但你就是覺得哪裡怪怪的。 也許邊界有點模糊。也許 contract 只是被暗示，卻沒有被明確寫出來。也許 happy path…