構建之法第四章兩人合做

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

2.性格對合做的影響
人和人不同，在和別人合做的時候，要注意各人表達觀點的方式和思考的方式不盡相同。請看網上關於MB TI的文章[註釋4]，測試並分享各自的MB TI類型，討論不一樣性格類型對合做有多大的影響，在合做的各個階段應該如何應對[註釋5]。
(1)這個是個人測試：http://www.apesk.com/mbti/submit_email_date_cx_m.asp?code=223.104.101.170&user=16278023
(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）在看別人編程時，修改代碼時，由於不熟悉別人的代碼，修改時大幅度的跳躍和轉換，讓人不知道整個工程的現狀。這個時候能夠適當讓實施者停下，和他討論修改或者跳躍的緣由，理清思路。