程序員寫的代碼最終是人在看，所以代碼規範很重要，原則是：簡明，易讀，無二義性。

不光是程序書寫的格式問題，還牽涉到程序設計、模塊之間的關系、設計模式等方方面面。

代碼復審的正確定義看代碼是否在代碼規範的框架內正確的解決了問題

代碼復審的目的在於：

1.找出代碼的錯誤，比如：

1）編碼錯誤，比如一些碰巧騙過了編譯器的錯誤

2） 不符合團隊代碼規範的地方

2. 發現邏輯錯誤，程序可以編譯通過，但是代碼的邏輯是錯的

3. 發現算法錯誤，比如使用的算法不夠優化，邊界條件沒有處理好等

4. 發現潛在的錯誤和回歸性錯誤—當前的修改導致以前修復的缺陷又重新出現

5. 發現可能需要改進的地方

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

結對編程讓兩個人所寫的代碼不斷地處於“復審”的過程，程序員們能夠不斷地審核，提高設計和編碼質量，可以及時發現並解決問題，避免把問題拖到後面的階段去。

開發中的復審主要包括：設計復審、代碼復審、測試計劃復審和文檔復審。

這些復審可以在夥伴之間進行，也可以在團隊內部進行。

兩個人合作的不同階段

1. 萌芽階段（Forming） 兩人剛剛互相認識，這時大家都有禮貌，一般交流不少，雙方彼此並不了解。

2. 磨合階段（Storming）

3. 規範階段（Norming）

4. 創造階段（Performing）

5. 解體階段（Deforming）

如何正確的給予反饋

1.最外層：行為和後果

行為可以改正，後果可以彌補，還有挽回局面的機會

2.中間層：習慣和動機

被攻擊的一方就比較難表白並且澄清動機

3.最內層：本質和固有屬性

當攻擊深入到核心，被攻擊一方已經無法回應

如果軟件工程師連一對一的合作都做不好，不能有效地影響同伴，讓合作雙方都從中受益，提高水平的話，更別提團隊合作了，影響了團隊合作，從而影響了整個公司的利益。

所以首先要做好兩個人的合作

兩人的合作—如何影響對方

兩人在一起合作，自然會出現不同意見，每個人都有自己的想法，在兩個人平等合作的情況下，不存在領導與被領導的關系，如何能說服對方？這個時候不是比誰的嗓門大，首先雙方要意識到，問題早點出現要比晚點出現好很多，我們有機會早日解決問題。除了技術方面的考慮之外，一個成熟的工程師要琢磨對方的話語和觀察對方的肢體語言，了解它們所表示的潛臺詞，試著從對方的角度看待問題。

讀構建之法 第四章：兩人合作