3.2.2　檢查議程與注意事項

在代碼檢查之前的幾天，協調人將程序清單和設計規范分發給其他成員。所有成員應在檢查之前熟悉這些材料。在檢查進行時，主要進行兩項活動：

1.由程序編碼人員逐條語句講述程序的邏輯結構。在講述的過程當中，小組的其他成員應提問題、判斷是否存在錯誤。在講述中，很可能是程序編碼人員本人而不是其他小組成員發現了大部分錯誤。換句話說，對著大家大聲朗讀程序，這種簡單的做法看來是一個非常有效的錯誤檢查方法。

2.參考常見的編碼錯誤列表分析程序（錯誤列表將在下一節中介紹）。

協調人負責確保檢查會議的討論高效地進行、每個參與者都將注意力集中于查找錯誤而不是修正錯誤（錯誤的修正由程序員在檢查會議之后完成）。

會議結束之后，程序員會得到一份已發現錯誤的清單。如果發現的錯誤太多，或者某個錯誤涉及對程序做根本性的改動，協調人可能會在錯誤修正后安排對程序進行再次檢查。這份錯誤清單也要進行分析、歸納，用以提煉錯誤列表，以便提高以后代碼檢查的效率。

如上所述，這個代碼檢查過程通常將注意力集中在發現錯誤上，而不是糾正錯誤。然而，有些小組可能會發現，當檢查出某個小問題之后，有兩三個人（包括負責該代碼的程序員本人）會建議對設計進行明顯的修補以解決這個特例。那么，對這個小問題的討論，反過來會將整個小組的注意力集中在設計的某個部分。在探討修補設計來解決這個小問題的最佳方法時，有人可能會注意到另外的問題。既然小組已經發現了設計中同一部分的兩個相關問題，那么每隔幾段代碼就可能需要密集的注釋。幾分鐘之內，整個設計就被徹底檢查完，任何問題都會一目了然。

在代碼檢查的時間及地點的選擇上，應避免所有的外部干擾。代碼檢查會議的理想時間應在90～120分鐘。由于開會是一項繁重的腦力勞動，會議時間越長效率越低。大多數的代碼檢查都是按每小時大約閱讀150行代碼的速度進行。因此，對大型軟件的檢查應安排多個代碼檢查會議同時進行，每個代碼檢查會議處理一個或幾個模塊或子程序。