關於Peer Review、程式碼評審和測試驅動

相關的文件請參看：

關於程式碼評審，中國很多公司早就有這個做法了。我今天跟金蝶的溫少討教過這個問題，他提出了不少好建議，先摘錄如下：

你可以把專案組中的每個人的程式碼都抽取部分給其他人審查。最好有辦法避免開發者把最好的程式碼提交評審。

每幾個人負責評審一塊的程式碼，最好能夠熟悉對方的業務或者程式

最初時，通常只能檢查到一些程式碼中的容易發現的錯誤，例如編碼不規範和一些很顯而易見的錯誤，不過單這一些就很重要了

你最好讓大家花時間自己整理一下程式碼，然後提交評審。評審的時候，最好有投影儀，大家坐在一個電腦前面，輪流講自己評審別人的程式碼中發現的問題和優點

當然，發現了問題，如果確定了要修改的，會錄入研發管理平臺中作為待處理任務的

不單要發現問題去解決，也要發現優點推廣之

你先做一次，你就會發現，這個過程會很愉快，因為發現了很多可笑的程式碼，同時你要注意協調，讓這個過程愉快一些

最初只能做編碼規範和一些簡單錯誤的檢查。你去審查一遍大家的程式碼，你可能也能總結一些和自己所採用技術相關的規則，你目前的一些評審專案可能還可以細化和補充

建議補充一條，是否檢查了在函式入口處檢查了引數的合法性，如果檢查了，做優點處理。

呼叫別人的函式，返回值，是否進行了合法性檢查或者空值處理。例如if (rtnVal != null) 。通常如果做了，當優點處理

這兩條，能夠提高程式碼的質量，因為程式中，通常會很容易產生因為引數或者返回值不恰當導致的錯誤，這類錯誤的錯誤資訊通常比較亂，很難查。

這個要求有些高的，所以如果做了，當優點處理。

當然，資料庫可以檢查命名規範，是否使用不恰當的資料型別

程式碼評審的目的：

設計和開發評審的目的是由一組有資格的人員對軟體設計和開發的輸出進行評價，以判斷確定設計和開發的輸出能否實現軟體產品預先定義的規格，同時通過評審標識出與規格和標準的偏差。它向管理部門提供充足的證據以證明
　　1）設計和開發的輸出符合了其規格要求；
　　2）設計和開發的輸出是否滿足相關法律、法規以及企業標準的要求；
　　3）軟體產品的更改得到了恰當地實施；
　　4）軟體產品的更改只對那些規格發生了更改的系統區域有影響，沒有引入新的問題。

相關的文件請參看：http://www.chinauml.net/software_engineering/rjzl/20040429/151346.html

程式碼評審時應該有一依據，並根據這一依據進行評審，把評審結果詳細記錄下來，這就是程式碼評審報告。我在網路上搜尋很久都沒有這樣的文件，於是就自己寫了一個，並實際運用起來。