《建構之法》讀書筆記第四章——結對程式設計

本章節講的是結對程式設計和結對程式設計應當注意的地方，結對程式設計也是軟工經典《人月神話》最推崇的程式設計方式之一，最早的結對程式設計記錄是：

1987年，Intuit公司（當時隻是一個剛剛起步的個人财務管理軟體公司）宣布4月會向客戶提供新版本的軟體（4月15日是美國報稅的截止日期）。但到了3月末，公司僅有的兩個技術人員發現進度還是大大落後于預期，于是這兩人在3月的最後一周開展了不得已的、長達60個小時的結對程式設計活動

這段經曆在《人月神話》中也有記載。結對程式設計有以下好處：

1. 結對和單獨開發相比，能保持一定的壓力，鼓勵雙方保持代碼的高品質
2. 改善代碼品質，增加代碼的可讀性和可禮節性
3. 提高程式設計效率，往往能更快的編寫代碼，并導緻代碼的錯誤更少。

但是結對程式設計畢竟屬于兩人合作範疇的，如果兩人程式設計習慣迥異，在一起工作中說不定會産生不小的麻煩。

此外，對于程式猿而言，代碼時寫給機器看到還是給人看的呢？

人也看，機器也看，但是最終是人在看。

書中這樣說道。畢竟是給人看的，是以寫代碼的一定要注意代碼規範，而代碼規範分文兩個部分：

1. 代碼風格規範

   代碼風格的原則是：簡明，易讀，無歧義。其中變量名和注釋是需要特别的地方。注釋應隻用ASCII字元，如果用中文字元做注釋，在遷移時很有可能因為解碼方式的不同造成中文字元變成亂碼。

2. 代碼設計規範

   除了書寫格式問題外，還應注意程式設計和子產品之間的關系，其中最需要注意的是函數

   隻做一件事，并且要做好

寫好代碼以後，不能忘記的還有代碼複審。代碼複審的目的是在項目早期發現其中的錯誤，并且能達到交流、互相教育學習、傳授經驗的目的。

做好一個事情最好能有回報，無論是正面還是反面的，而代碼複審就是寫代碼過程中的一個重要回報來源之一。而結對程式設計能做到時刻代碼複審，一般來說結對程式設計有兩個角色：駕駛員和領航員，一個負責編寫代碼，一個負責監督和提醒，領航員提醒的過程也是不間斷的代碼複審過程。

所謂對事不對人，回報也要注意方式方法。一般來說對人的評價是從以下三個方面展開的。

1.最外層：行為和後果

2.中間層：習慣和動機

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

書中提到了一個“三明治”的方法：

最好是先來一片面包，做好鋪墊：強調雙方的共同點，從團隊共同的願景講起，讓對方覺得處于一個安全的環境。

然後再把肉放上，這時就可以把建設性的意見（ConstructiveFeedback）加工好，加上生菜、佐料等。怎麼準備這塊肉也有講究，在提供回報時，不宜完全沉溺于過去的陳年谷子爛芝麻，給别人做評價，下結論。這樣會造成一種[你就是做得不好，我恨你]的情緒。不妨換個角度，展望将來的結果，強調[過去你做得不夠，但是我們以後可以做得更好]。在技術團隊裡，我們的回報還是要着重于[行為和後果]這一層面，不要貿然深入到[習慣和動機]、[本質]。除非情況非常嚴峻，需要觸動别人内心深處，讓别人懸崖勒馬。然後再來一片面包，呼應開頭，鼓勵對方把工作做好

生活中的溝通也可以借鑒”三明治“方法，從雙方基礎談起，再書名建設性意見，最後再鼓勵一下對方。似乎，我女朋友訓我的時候也是這樣的模型，咳咳，扯遠了。

總之，結對程式設計是能加深團隊成員了解，快速提高項目進度，1+1>2的一種不錯的程式設計方法。