1、結對項目的案例和論文
學術界、工業界對結對編程已經有不少研究，請閱讀至少兩篇相關論文或論文，結合自己的切身體會總結一下。
（1）提高效率
　　結對編程的形式使得代碼處於不斷地審查過程，每一段代碼都由一個人編寫，另一個人檢查，最大程度上減少了出現bug的可能；兩人互相交流，商討實現方式，遇到問題時，能夠做到互補。
（2）互相學習
　　結對編程也是一個互相學習的過程。在結對編程過程中，兩人會不斷對實現方法、代碼風格或命名方法等進行討論，兩個人的思路能夠進行互補，在編寫過程中能夠學到對方解決問題的思路和方法，對於提高自己解決問題和編程能力有很大的幫助。

2.性格對合作的影響
人和人不一樣，在和別人合作的時候，要註意各人表達觀點的方式和思考的方式不盡相同。請看網上關於MB TI的文章[註釋4]，測試並分享各自的MB TI類型，討論不同性格類型對合作有多大的影響，在合作的各個階段應該如何應對[註釋5]。
(1)這個是我的測試：http://www.apesk.com/mbti/submit_email_date.asp?code=223.73.241.5&user=16614475
(2)
外向（E）和內向（I）
感覺（S）和直覺（N）
思考（T）和情感（F）
判斷（J）和知覺（P）

ISTJ

安靜、嚴肅，通過全面性和可靠性獲得成功。實際，有責任感。決定有邏輯性，並一步步地朝著目標前進，不易分心。喜歡將工作、家庭和生活都安排得井井有條。重視傳統和忠誠。

ISFJ

安靜、友好、有責任感和良知。堅定地致力於完成他們的義務。全面、勤勉、精確，忠誠、體貼，留心和記得他們重視的人的小細節，關心他人的感受。努力把工作和家庭環境營造得有序而溫馨。

INFJ

尋求思想、關系、物質等之間的意義和聯系。希望了解什麽能夠激勵人，對人有很強的洞察力。有責任心，堅持自己的價值觀。對於怎樣更好的服務大眾有清晰的遠景。在對於目標的實現過程中有計劃而且果斷堅定。

INTJ

在實現自己的想法和達成自己的目標時有創新的想法和非凡的動力。能很快洞察到外界事物間的規律並形成長期的遠景計劃。一旦決定做一件事就會開始規劃並直到完成為止。多疑、獨立，對於自己和他人能力和表現的要求都非常高。

ISTP

靈活、忍耐力強，是個安靜的觀察者直到有問題發生，就會馬上行動，找到實用的解決方法。分析事物運作的原理，能從大量的信息中很快的找到關鍵的癥結所在。對於原因和結果感興趣，用邏輯的方式處理問題，重視效率。

ISFP

安靜、友好、敏感、和善。享受當前。喜歡有自己的空間，喜歡能按照自己的時間表工作。對於自己的價值觀和自己覺得重要的人非常忠誠，有責任心。不喜歡爭論和沖突。不會將自己的觀念和價值觀強加到別人身上。

INFP

理想主義，對於自己的價值觀和自己覺得重要的人非常忠誠。希望外部的生活和自己內心的價值觀是統一的。好奇心重，很快能看到事情的可能性，能成為實現想法的催化劑。尋求理解別人和幫助他們實現潛能。適應力強，靈活，善於接受，除非是有悖於自己的價值觀的。

INTP

對於自己感興趣的任何事物都尋求找到合理的解釋。喜歡理論性的和抽象的事物，熱衷於思考而非社交活動。安靜、內向、靈活、適應力強。對於自己感興趣的領域有超凡的集中精力深度解決問題的能力。多疑，有時會有點挑剔，喜歡分析。

ESTP

靈活、忍耐力強，實際，註重結果。覺得理論和抽象的解釋非常無趣。喜歡積極地采取行動解決問題。註重當前，自然不做作，享受和他人在一起的時刻。喜歡物質享受和時尚。學習新事物最有效的方式是通過親身感受和練習。

ESFP

外向、友好、接受力強。熱愛生活、人類和物質上的享受。喜歡和別人一起將事情做成功。在工作中講究常識和實用性，並使工作顯得有趣。靈活、自然不做作，對於新的任何事物都能很快地適應。學習新事物最有效的方式是和他人一起嘗試。

ENFP

熱情洋溢、富有想象力。認為人生有很多的可能性。能很快地將事情和信息聯系起來，然後很自信地根據自己的判斷解決問題。總是需要得到別人的認可，也總是準備著給與他人賞識和幫助。靈活、自然不做作，有很強的即興發揮的能力，言語流暢。

ENTP

反應快、睿智，有激勵別人的能力，警覺性強、直言不諱。在解決新的、具有挑戰性的問題時機智而有策略。善於找出理論上的可能性，然後再用戰略的眼光分析。善於理解別人。不喜歡例行公事，很少會用相同的方法做相同的事情，傾向於一個接一個的發展新的愛好。

ESTJ

實際、現實主義。果斷，一旦下決心就會馬上行動。善於將項目和人組織起來將事情完成，並盡可能用最有效率的方法得到結果。註重日常的細節。有一套非常清晰的邏輯標準，有系統性地遵循，並希望他人也同樣遵循。在實施計劃時強而有力。

ESFJ

熱心腸、有責任心、合作。希望周邊的環境溫馨而和諧，並為此果斷地執行。喜歡和他人一起精確並及時地完成任務。事無巨細都會保持忠誠。能體察到他人在日常生活中的所需並竭盡全力幫助。希望自己和自己的所為能受到他人的認可和賞識。

ENFJ

熱情、為他人著想、易感應、有責任心。非常註重他人的感情、需求和動機。善於發現他人的潛能，並希望能幫助他們實現。能成為個人或群體成長和進步的催化劑。忠誠，對於贊揚和批評都會積極地回應。友善、好社交。在團體中能很好地幫助他人，並有鼓舞他人的領導能力。

ENTJ

坦誠、果斷，有天生的領導能力。能很快看到公司/組織程序和政策中的不合理性和低效能性，發展並實施有效和全面的系統來解決問題。善於做長期的計劃和目標的設定。通常見多識廣，博覽群書，喜歡拓廣自己的知識面並將此分享給他人。在陳述自己的想法時非常強而有力。
3.是否需要有代碼規範
對於是否需要有代碼規範[註釋6]，請考慮下列論點並反駁/支持：
1）這些規範都是官僚制度下產生的、浪費大家的編程時間、影響人們開發效率、浪費時間的東西。
2）我是個藝術家，手藝人，我有自己的規範和原則。
3）規範不能強求一律，應該允許很多例外。
4）我擅長制定編碼規範，你們聽我的就好了。代碼復審檢查表：
答：1）不支持這個觀點。代碼規範並不是官僚主義的產物，而是為了增加代碼的可讀性，使代碼變得易讀且易維護。書寫符合代碼規範的代碼並不會降低開發效率，相反，這樣做可以提高人們的開發、維護效率。在剛開始寫代碼的時候，老師就叮囑我們要培養一個良好的代碼風格，不僅僅是為了自己在以後閱讀的時候能夠方便簡單的讀懂，也是為了便於他人閱讀理解。尤其是在團隊合作的時候，如果每個人都很隨意的自己用自己的方式，不僅不好維護，互相也不能理解代碼意思。這樣反而拖延工作量，浪費時間，降低效率。
就好比無規矩不成方圓，如果每個人都堅持自己的代碼風格不做規範，那麽在代碼交接的時候會因為彼此的意見觀點不同發生沖突更讓人厭煩。所浪費的時間要比制定規範的時候浪費的更多。
2）觀點2，不支持這種觀點。編程的藝術不是從代碼規範中體現的，代碼的藝術更多的體現在算法設計、數據結構的選取等方面。符合一定的公認的代碼規範只會為我們的代碼添彩，不會降低代碼的藝術性。我認同程序員也可以稱得上藝術家，我們和他們的不同就是我們的藝術發揮在機器上。每個人都是不一樣的，每個人都有自己的習慣愛好，就如同每一位藝術家手藝人都會用自己的方式在作品上留下屬於自己的記號，但是很多時候不是獨特才是最好的，有許多事並不一定有什麽最佳答案，只要能解決問題的方法就是好方法。同樣，規範風格有時候也談不上是不是最好的，應用起來方便、高效，這就是好規範。

3）觀點3，不支持這種觀點。每個團隊都可以制定自己的代碼規範，但是這也是要建立在一定的公認的基礎上的。因為公認的代碼規範之所以能流傳下來，一定有他的道理，這樣的代碼規範符合人們對代碼的認知，便於大家理解代碼。國家政策也是根據地區不同制定不同的規則。代碼規範也不是強制的全部一模一樣。如果遇到一些因為代碼規範不能解決的問題，那麽就不得不變通了。對於一個團隊而言，我們每個人都只是一份子沒有誰是絕對的獨裁者，因為合作所以我們要照顧每個人的風格
4）觀點4，不支持這種觀點。一個團隊的代碼規範往往需要結合大家的意願來制定，一些規範（比如大括號不換行和大括號換行的兩種信仰……）不能僅聽一個人的，而應符合大多數人的習慣。這種想法不僅僅是在碼代碼的合作時不能有這種想法，為人處世其他方面也都厭煩這種專制。
4.代碼復審的討論
小飛：哇，這麽多酷的C++功能都不能用，那我們還學什麽C++，為了迎接考試，我都把OperatorOverload、Polymorphism背得滾瓜爛熟了，為什麽不讓我用？
阿超：我們寫程序是為了解決問題，不是“為賦新詞強說愁”，這些高級的語言特性，不是不讓用，而是要用得慎重，不要動不動就寫三五個類，一個套一個，要把註意力集中在能否用簡潔的方法解決問題上來。
小飛：這麽多規範，我都不知道怎麽寫第一行程序了。
阿超：自我復審也很重要——把代碼擺在面前，當作是別的菜鳥寫的。把你通常問別人的，以及別人會問你的問題都自己問一遍，這樣就能發現不少問題。
小飛：如果開發者很厲害，那麽復審者就沒有什麽作用，也許這些復審都是走過場？
阿超：同理可以推論，如果開發者很厲害，那麽測試人員也沒什麽作用，也是走過場，幹脆把他們送回家得了。我們敢這樣做麽？
小飛：這些規範啊，建議啊，都是細枝末節的東西，我們要做世界級的軟件，搞這些東西是不是太小家子氣了？
阿超：首先世界級的軟件也會因為小小的紕漏而導致世界級的問題。例如我們常常聽到的安全漏洞和緊急補丁。其次，軟件的開發是一個社會性的活動，有它的規律。其中一個規律就是“破窗效應”（Broken Windows Theory），如果團隊成員看到同伴們連一些細小的規範都不遵守，那自己還要嚴格執行單元測試麽？另一個成員看到這個模塊連單元測試都沒有，那他自己也隨意修改算了。這樣下去，整個軟件的質量可想而知。
答： 首先世界級的軟件也會因為小小的紕漏而導致世界級的問題。例如我們常常聽到的安全漏洞和緊急補丁。其次，軟件的開發是一個社會性的活動, 有它的規律。其中一個規律就是“破窗效應”，如果團隊成員看到同伴們連一些細小的規範都不遵守，那自己還要嚴格執行單元測試麽？另一個成員看到這個模塊連單元測試都沒有，那他自己也隨意修改算了。這樣下去，整個軟件的量可想而知。所以代碼應該復審，規範應該要保持。
5.閱讀別人的代碼有多難？我們經常抱怨閱讀別人的代碼很難，我們自己在寫代碼的時候，是否考慮到如何讓代碼更易於閱讀和維護呢？
https://kb.cnblogs.com/page/192086/
(1)堅持使用一種命名模式
如果你打算用匈牙利命名法，那就堅持並廣泛使用，否則將適得其反。使用匈牙利命名法來記錄數據，而不是存儲類型；記錄普遍事實，而不是臨時條件。
(2) 別縮寫英文單詞
確切來說，別縮寫成稀奇古怪的形式。
6.結對編程中不好的習慣—你經歷過麽，如何提醒同伴改進？
不拘小節的人　兩人在一起近距離地工作，但是卻不註意個人衛生和互相尊重。開始合作前，吃了很多大蒜就來了。
喜歡發號施令的人　總是對敲鍵盤的人說：“到末行，加個反括號，然後……”。他不去關註解決方法和下一步該怎麽做，而過度關註一些編程細節。
拼寫糾錯者　坐在你旁邊，糾正你輸入的每個錯誤字符。當然，他沒有時間來真正地進行導航。
深藏不露者　僅僅自己敲著代碼而不告訴別人他在做什麽。領航員不得不靠自己去弄懂代碼。關於該用什麽方法，該選擇哪種設計，領航員和實施者之間完全沒有交流。
跳躍很大的人　他們喜歡在代碼中進行大範圍的跳躍，這樣領航員便不知道進行到哪裏了。
答：（1）個人的儀表是對對方的尊重，如果我的同伴真的這樣，首先我會提出一起去外面咖啡廳工作或者討論，這樣一般就會適當得體一些，並且給他口香糖吃。
（2）首先要肯定對方的提醒，其次也向他提出，我們應該首先解決問題，等一下再一起糾正這些編程規範。
（3）好像是開車的時候被人不斷提醒一樣，有的時候這點確實讓人心焦，尤其是很多的拼寫錯誤都是一時手誤而且編程工具會自動提醒，當遇到這樣的夥伴時，我覺得應該引導他像別的方向註意，在編程前就提出一定的問題希望幫忙留意。讓其把重點放在代碼上。
（4）一個組裏往往會有一個超過別人很多的人，他的思路和使用的新的技術往往讓人一頭霧水。結構和代碼也不太理解。這個時候應該做出改變的不只是實施者，還有看代碼的人，要直接提出疑問，讓實施者回答，並且多進行討論交流意見，並且希望在編程中註釋。
（5）在看別人編程時，修改代碼時，因為不熟悉別人的代碼，修改時大幅度的跳躍和轉換，讓人不知道整個工程的現狀。這個時候可以適當讓實施者停下，和他討論修改或者跳躍的原因，理清思路。

現代軟件工程第四章