Code Review 指引
為什麼需要 Code Review 要瞭解為什麼需要 code review 之前,先透過下面這張圖解釋,隨著軟體開發週期越後面的階段或經歷的時間越長,軟體修復 bug 的成本越高。 ▲圖 1 軟體修復成本與時間關係(資料來源: https://buildsecurityin.us-cert.gov/articles/best-practices/security-testing/risk-based-and-functional-security-testing ) 為什麼越晚修復,成本會越高呢?這跟技術債的情況相同,債會生利息,而這利息與循環利息和複利一樣可怕。開發越後期大樓越蓋越歪,疊床架屋與貪快累積的技術債將導致程式包袱越大,也越難維護。然而也因為只要是程式就一定會有 bug ,而越晚修復 bug 的成本越高,因此在各個開發團隊中,希望有效降低軟體維護成本最佳的方式,就是下列兩種: 提早發現 bug 並進行修復,讓 X 軸的值小一點,自然 Y 軸所代表的成本就低一些。 讓程式儘可能地好維護一些,以減緩成本上升的曲線斜率。一旦曲線平緩一些,Y 軸所代表的成本自然也會低一點。 而進行 code review 則是有效滿足上面兩個目的: 提早發現 bug 且修復,並讓程式好維護一些 。 什麼是 Code Review 程式一定有 bug 主要是因為開發人員很容易陷入自己的盲點,常見的盲點有兩種: 程式是照你寫的跑,不是照你想的跑。 程式照你想的跑,但你想的是錯的。 要突破上述的盲點,最簡單的方式就是找別人來 review 你開發中或開發完的程式,跟你一起確認程式是否寫的跟你想的一樣,以及確認你想的是對的。 註:當然,review 開發中或開發完的程式所發現 bug 的時間點,就是上圖的 Development 階段,如果希望能在 Design 與 Developer 階段中就發現問題,來讓 bug 根本不會發生,或是在第一時間點就被修復,這就是 極限編程 (eXtreme Programming) 中所提倡的 搭檔編程 (pair programming) ,這在實務上更是挑戰工程師的人性以及管理者的極限,但以 bug 修復成本的角度來看,這的確花費的成本最低。 簡單的說 ...