代碼複審和兩人合做

代碼複審的步驟：

• 代碼必須成功地編譯，在全部要求的平臺上，同時要編譯DeBug| Retail版本。編譯要用團隊規定的最嚴格的編譯警告等級（例如C/C++中的W4）。
• 程序員必須測試過代碼。什麼叫測試過？最好的方法是在DeBugger中單步執行。
• 程序員必須提供新的代碼，以及文件差別分析工具。Windiff或VSTS自帶的工具均可以。VSTS中能夠經過Shelveset來支持遠程代碼複審。
• 複審者能夠選擇面對面的複審、獨立複審或其餘方式。
• 在面對面的複審中，通常是開發者控制流程，講述修改的來龍去脈。可是複審者有權在任什麼時候候打斷敘述，提出本身的意見。
• 複審者必須把反饋意見逐一提出。注意，複審者有權提出不少看似吹毛求疵的問題，複審者沒必要每一件事都要親自調查，開發者有義務給出詳盡的回答。
• 開發者必須負責讓全部的問題都獲得滿意的解釋或解答，或者在TFS中建立新的工做項以確保這些問題未來會獲得處理。
• 對於複審的結果，雙方必須達成一致的意見。                                 

複審的目的在於：

（1）找出代碼的錯誤。如：a. 編碼錯誤，好比一些能碰巧騙過編譯器的錯誤。

b. 不符合項目組的代碼規範的地方。

（2）發現邏輯錯誤，程序能夠編譯經過，可是代碼的邏輯是錯的。

（3）發現算法錯誤，好比使用的算法不夠優化。

（4）發現潛在的錯誤和迴歸性錯誤——當前的修改致使之前修復的缺陷又從新出現。

（5）發現可能改進的地方。

（6）教育（互相教育）開發人員，傳授經驗，讓更多的成員熟悉項目各部分的代碼，同時熟悉和應用領域相關的實際知識。                                 

兩人合做:兩人在一塊兒合做，天然都有本身的想法，在兩人平等合做的狀況下，不存在領導與被領導的關係。沒有絕對正確或錯誤的方法，只有合適或不合適的方法。兩我的的水平、目標不一致，不可能沒有矛盾。任何人都不是完美的，都有能夠改進的空間，在不斷的改進中，團隊之間相互磨合，最終共同完成任務。