本章節講的是結對程式設計和結對程式設計應當注意的地方，結對程式設計也是軟工經典《人月神話》最推崇的程式設計方式之一，最早的結對程式設計記錄是：
2023年，intuit公司（當時只是乙個剛剛起步的個人財務管理軟體公司）宣布4月會向客戶提供新版本的軟體（4月15日是美國報稅的截止日期）。但到了3月末，公司僅有的兩個技術人員發現進度還是大大落後於預期，於是這兩人在3月的最後一周開展了不得已的、長達60個小時的結對程式設計活動這段經歷在《人月神話》中也有記載。結對程式設計有以下好處：
結對和單獨開發相比，能保持一定的壓力，鼓勵雙方保持**的高質量
改善**質量，增加**的可讀性和可禮節性
提高程式設計效率，往往能更快的編寫**，並導致**的錯誤更少。
但是結對程式設計畢竟屬於兩人合作範疇的，如果兩人程式設計習慣迥異，在一起工作中說不定會產生不小的麻煩。
此外，對於程式猿而言，**時寫給機器看到還是給人看的呢？
人也看，機器也看，但是最終是人在看。書中這樣說道。畢竟是給人看的，因此寫**的一定要注意**規範，而**規範分文兩個部分：
**風格規範
**風格的原則是：簡明，易讀，無歧義。其中變數名和注釋是需要特別的地方。注釋應只用ascii字元，如果用中文字元做注釋，在遷移時很有可能因為解碼方式的不同造成中文字元變成亂碼。
**設計規範
除了書寫格式問題外，還應注意程式設計和模組之間的關係，其中最需要注意的是函式
只做一件事，並且要做好
寫好**以後，不能忘記的還有**複審。**複審的目的是在專案早期發現其中的錯誤，並且能達到交流、互相教育學習、傳授經驗的目的。
做好乙個事情最好能有反饋，無論是正面還是反面的，而**複審就是寫**過程中的乙個重要反饋**之一。而結對程式設計能做到時刻**複審，一般來說結對程式設計有兩個角色：駕駛員和領航員，乙個負責編寫**，乙個負責監督和提醒，領航員提醒的過程也是不間斷的**複審過程。
所謂對事不對人，反饋也要注意方式方法。一般來說對人的評價是從以下三個方面展開的。
1.最外層：行為和後果書中提到了乙個「三明治」的方法：2.中間層：習慣和動機
3.最內層：本質和固有屬性
最好是先來一片麵包，做好鋪墊：強調雙方的共同點，從團隊共同的願景講起，讓對方覺得處於乙個安全的環境。生活中的溝通也可以借鑑」三明治「方法，從雙方基礎談起，再書名建設性意見，最後再鼓勵一下對方。似乎，我女朋友訓我的時候也是這樣的模型，咳咳，扯遠了。然後再把肉放上，這時就可以把建設性的意見（constructivefeedback）加工好，加上生菜、佐料等。怎麼準備這塊肉也有講究，在提供反饋時，不宜完全沉溺於過去的陳年穀子爛芝麻，給別人做評價，下結論。這樣會造成一種[你就是做得不好，我恨你]的情緒。不妨換個角度，展望將來的結果，強調[過去你做得不夠，但是我們以後可以做得更好]。在技術團隊裡，我們的反饋還是要著重於[行為和後果]這一層面，不要貿然深入到[習慣和動機]、[本質]。除非情況非常嚴峻，需要觸動別人內心深處，讓別人懸崖勒馬。然後再來一片麵包，呼應開頭，鼓勵對方把工作做好
總之，結對程式設計是能加深團隊成員了解，快速提高專案進度，1+1>2的一種不錯的程式設計方法。
《構建之法》 第四章
本章內容是講 兩人合作 眾所周知 三個臭皮匠賽過諸葛亮 無論是從事什麼活動或者工作，可見合作的力量是1 1 2 一 重要性 軟體開發的過程是複雜的，顯然的乙個人的智慧型是不夠的，遇到問題一起解決，工作一起分擔能使開發的效率提高很多。以後到公司團隊工作，合作很大程度上實現優勢互補，比如說有人擅長介面設...
第四章 讀書筆記
源 包含了許多的東西，包括 android 應用程式的 android sdk 自帶的工具，android ndk 的源 等等，所以單從數量上來講，android linux 終端執行命令來配置 android12 repo 指令碼檔案 3 建立用於存放 android 源 的目錄 4 初始化 5a...
結對程式設計 《構建之法》讀書筆記
一周的時間，初次體驗了結對程式設計。首先感謝我的搭檔婁雨稹同學，非常給力，合作的非常愉快。下面寫一下第一次結對程式設計的體驗 部分和書中相似，還有一些不同的地方 此次程式設計需要使用c 來寫qt，由於我們兩個對c 都不熟悉，最開始的時候我們選擇分開學習各自探索。學了兩天後大致有些了解，我們開始交流自...