兩人合作是團隊合作的基礎；這裏介紹的這個基礎型“團隊”中通用的一些方法以及最重要的——交流——的細節

1.代碼規範

1. 代碼風格規範。主要是文字上的規定；
   • 縮進：4個空格，而不是tab；
   • 關於斷行與空白的{}行
   • 下劃線：用來分割變量名字中的作用域標註和變量的語義
   • 大小寫：通用的做法是，所有的類/函數名都采用所有單詞首字母大寫（Pascal）的形式；所有的變量首字母小寫，隨後的單詞首字母大寫(Camel)；
   • 註釋：解釋程序做什麽、為什麽這樣做以及要特別註意的地方。註釋只用ASCII碼字符，不要用中文或者其他特殊字符，否則會影響可移植性
2. 代碼設計規範。牽涉到程序設計、模塊之間的關系、設計模式等思維和價值觀角度的東西。
   • 函數：只做一件事，做到最好。
   • 函數：最好有單一的出口，必要的時候可以使用goto；
   • 錯誤處理：
     • 參數處理：在debug版本中，所有的參數都要驗證其正確性；
     • 斷言：Assert(一定正確的某條語句)

2.代碼復審

代碼復審的目的在於找出代碼的錯誤。因為越是項目後期發現的錯誤，修復的代價就越大——這也是learning by doing思想的體現。

• 代碼審核表應該囊括（不局限於）這些方面
  • 概要部分（整體風格）
  • 設計規範部分（按照已知的規則去約束）
  • 代碼規範部分
  • 具體代碼部分
  • 效能
  • 可讀性
  • 可測試性【我認為其實最後兩個是一種“精益求精”的標準】

3.結對編程

1. 結對編程中有兩個角色
   1. 駕駛員（driver）：控制鍵盤輸入；
   2. 領航員（navigator）：領航提醒。
2. 在結對編程的過程中不斷重復的互相復審
   1. 傳統復審最大的缺點是復審者缺少對程序的深入了解；
   2. 傳統復審設計人員多，復審效率不能平衡。互相復審則可以十分默契地提高效率；
   3. 結對編程最大的特點在於“領航員”的引入。如果實際中這個角色不能“領航”，則不如放棄結對編程
3. 極限編程
   • 把一些認為有效的方法發揮到極致（效用和占比最大化）
4. 關於交流的基本素質

讀完第四章《兩人合作》的內容後的總結