這一章講的是結對編程，結對編程的好處很多，有助于提升代碼質量，讓兩個人都對代碼負責，防止甩鍋扯皮。但是現實是基本沒有公司會這么干，畢竟對于很多中小型的公司來說，人力成本還是很高的。書中的一些編碼規范倒是值得學習的，包括代碼風格與設計規范。

代碼規范

代碼風格規范

• 1.縮進問題
  這個問題因人而異，我個人還是喜歡用tab鍵的，而且喜歡使用IDE的快捷鍵進行代碼格式化。
• 2.命名
  • 在變量名中不要提到類型或其他語法方面的描述。如表示全年假日的變量，不要用arraylistOfholidays，應該直接用holidays
  • 避免過多的描述，這樣會使變量名很長，不方便閱讀
  • 如果信息可以從上下文中得到，那么類信息就不必寫在變量名中。如在Teacher表中，變量不要寫teacherName，應該直接寫name
  • 大小寫：類/函數名用Pascal，變量用Camel
• 3.注釋
  • 注釋是為了解釋程序做了什么，為什么這么做，以及要特別注意的地方
  • 復雜的注釋應該放在函數頭
  • 注釋也要隨著程序的修改而不斷更新，畢竟一個誤導的注釋比沒有注釋更糟糕
    程序員討厭寫注釋，更討厭別人不寫注釋。我自己的注釋寫的很隨意，恐怕只有自己能看懂，這方面要改正。

代碼設計規范

• 函數：只做一件事，并且要做好。
  好像單一職責原則
• 構造函數
  • 不要在構造函數中做復雜的操作，簡單初始化所以數據成員即可
  • 構造函數不應該返回錯誤
• 運算符的實現必須非常有效率，如果有復雜的操作，應定義一個單獨的函數
  深以為然，自己就在判斷語句里寫過復雜的邏輯，導致維護比較麻煩
• 不要用異常作為邏輯控制來處理程序的主要流程

代碼審查

代碼審查的目的

• 找出代碼的錯誤
• 發現邏輯錯誤
• 發現算法錯誤
• 發現可能需要改進的地方
  我所在的團隊也做過代碼評審，但更多形式大于意義，坐在下面的同事更關心業務，而很少在代碼層面上提出意見。所以在輪完一遍之后，便沒有后續了。
  我是希望看到好的代碼的，也是樂于去學習的，比如他們用了好的設計模式或者算法，我就想去抄。
  而且閱讀優秀的代碼也是一種享受，也會激勵我更好的編程。畢竟知行要合一，好的編碼規范要在做中學。
  但我也很怕把自己的屎山代碼拉出來給眾人看，這種感覺真的不舒服，但也會鞭策我，讓我學習和模仿優秀的代碼。

做標記

• todo
• review
• bug
  我只用過todo，而且是濫用，定期review應該可以將標記清除，畢竟一個一年前的todo，現在也沒人敢動，不知道到底有沒有實現。

清除無用的代碼

很多人想保留盡可能多的代碼，因為以后可能會用上，這樣導致程序文件里有很多注釋掉的代碼，這些代碼都可以刪除，因為源代碼控制已經保存了原來的老代碼。
這個感觸挺深的，注釋掉的代碼看著很不爽，還有廢棄注解之類的東西，感覺沒用了干掉就完事了，無用的代碼反而誤導，明天就去把項目上用不到的代碼清除掉。