3.4　代碼走查

代碼走查與代碼檢查很相似，都是以小組為單位進行代碼閱讀，是一系列規程和錯誤檢查技術的集合。代碼走查的過程與代碼檢查大體相同，但是規程稍微有所不同，采用的錯誤檢查技術也不一樣。

就像代碼檢查一樣，代碼走查也是采用持續一至兩個小時的不間斷會議的形式。代碼走查小組由三至五人組成，其中一個人扮演類似代碼檢查過程中“協調人”的角色，一個人擔任秘書（負責記錄所有查出的錯誤）的角色，還有一個人擔任測試人員。關于這三到五個人的組成結構，有各種各樣的建議。當然，程序員應該是其中之一。我們建議另外的參與者應該包括：

·一位極富經驗的程序員；

·一位程序設計語言專家；

·一位程序員新手（可以給出新穎、不帶偏見的觀點）；

·最終維護程序的人員；

·一位來自其他不同項目的人員；

·一位來自該軟件編程小組的程序員。

開始的過程與代碼檢查相同：參與者在走查會議的前幾天得到材料，這樣可以專心鉆研程序。然而走查會議的規程則不相同。不同于僅閱讀程序或使用錯誤檢查列表，代碼走查的參與者“使用了計算機”。被指定為測試人員的那個人會帶著一些書面的測試用例（程序或模塊具有代表性的輸入集及預期的輸出集）來參加會議。在會議期間，每個測試用例都在人們腦中進行推演。也就是說，把測試數據沿程序的邏輯結構走一遍。程序的狀態（如變量的值）記錄在紙張或白板上以供監視。

當然，這些測試用例必須結構簡單、數量較少，因為人腦執行程序的速度比計算機執行程序的速度慢上若干量級。因此，這些測試用例本身并不起到關鍵的作用；相反，它們的作用是提供了啟動代碼走查和質疑程序員邏輯思路及其設想的手段。在大多數的代碼走查中，很多問題是在向程序員提問的過程中發現的，而不是由測試用例本身直接發現的。

與代碼檢查相同，代碼走查參與者所持的態度非常關鍵。提出的建議應針對程序本身，而不應針對程序員。換句話說，軟件中存在的錯誤不應被視為編寫程序的人員自身的弱點。相反，這些錯誤應被看做是伴隨著軟件開發的艱難性所固有的。

與代碼檢查過程中描述的相似，代碼走查應該有一個后續過程。同樣，代碼檢查所帶來的附帶作用（如可以發現易出錯的程序區域，通過接觸軟件錯誤、編程風格和方法來獲得教育等）同樣也會發生在代碼走查過程中。