前言
我認為《構建之法》這兩章為我們兩個人的結對合作和多人的團隊合作提供了很好的指導作用，也讓我們更加了解了軟件工程師的職業道德。分析了合作中可能遇到的各個時期和各種問題，讓我們更加了解了合作的形式與如何處理各種可能發生的情況。我相信認真閱讀后一定會對我們之后的項目和合作有幫助，避免一些不必要的問題影響我們的效率。同時，在閱讀的過程中，我也提出了一些問題和我的一些感悟，看法。具體問題如下：
第四章
1.“注釋（包括所有源代碼）應該只用ASCLL字符，不要用中文或其他特殊字符，否則會極大地影響程序的可移植性”
問題：
在4.1代碼規范的開頭，提到了這樣一句話，“程序員寫的代碼是給人看的，還是給機器看的？人也看，機器也看，但最終是人在看。”那注釋這個問題是否也應該根據編碼環境和程序員的水平來考慮是否可以使用中文呢？
我的看法：
首先我是認同注釋最好應該使用ASCLL編碼的，因為使用中文寫注釋容易出現亂碼的情況。的確影響了程序的可移植性，而且頻繁切換中英文加注釋是很影響編程的流暢性的。但是，既然注釋是為了讓別人更好的理解代碼，是不是可以靈活的根據實際情況決定注釋使用中文還是英文吶?英語的確很重要，但對於我們現在的水平，明顯閱讀中文能力更好，中文注釋能更好的更快的幫助我理解別人的程序，而不會因為不認識單詞或者英語語法問題而影響編程的效率。結合這樣的實際情況，我覺得可以根據隊友或者團隊人員的具體情況決定注釋的語言。
2. “函數最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程序邏輯的清晰體現，什么方法都可以使用，包括goto"
問題：
（1）goto語句一般不推薦使用的原因是什么？
（2）存在即合理。雖然不推薦使用，但其仍然存在就說明它在某些情況下還是有作用的。所有高級語言中都提供goto語句嗎？那么在什么語言，什么情況下可以考慮使用goto語句吶？
我的看法：
（1）根據這個問題，我也去查閱了一下相關的資料，首先得出了goto語句不建議使用的原因有：
a 在程序比較簡單時用goto語句是比較靈活，但是當程序比較復雜時很容易造成程序流程的混亂。
b 利用goto語句對以后的后別人看程序是很難理解。
c 調試程序的過程也會變得很困難。
（2）剛看到“函數最好有單一的出口”，不太理解這一目的和使用goto語句的關系。根據下面的講解我也更加深入的理解了goto語句的使用情況。“如今很多高級編程語言中，似乎是難以看見goto的身影：Java中不提供goto語句，雖然仍然保留goto為關鍵字，但不支持它的使用；C#中依然支持goto語句，但是一般不建議使用。其實可以很容易發現一點，這些不提倡使用goto語句的語言，大多是有自帶的垃圾回收機制，也就是說不需要過多關心資源的釋放的問題，因而在程序流程中沒有“為資源釋放設置統一出口”的需求。然而對於C++語言來說，程序員需要自己管理資源的分配和釋放。倘若沒有goto語句，那么我們在某個函數資源分配后的每個出錯點需要釋放資源並返回結果。雖然我們依然可以不使用goto語句完整地寫完流程，但是代碼將變得又臭又長。”（博文地址鏈接https://www.cnblogs.com/heartchord/p/4795337.html）閱讀后產生的疑問是：原文中“函數最好有單一的出口”是指這里提到的“為資源釋放設置統一出口”這個需求嗎？
3. “結對編程中有兩個角色，駕駛員和領航員。這兩個角色是可以互換的。和現實生活中的例子類似，一個人負責具體的執行，另一人負責導航，檢查，掩護等。”
問題：
閱讀到這里，不太理解兩個人結對編程的狀態。是兩個人必須針對整個項目中的同一功能一起解決，一個人負責這部分編程，另一個人負責統籌，檢查嗎？
我的看法：
之前我理解的結對編程是，開始時，兩個人一起討論，先統籌規划好整個項目的進度和解決各個問題的思路，然后就可以分模塊分功能，一人負責一部分。這樣的編程方式效率很高，完成項目的時間也會縮短。每人負責好自己那部分代碼的運行調試和復審，最后合並起來就是實現完整功能的代碼。可是看了書本上說，“結對編程避免了我的代碼還是他的代碼的問題，使得代碼的責任不屬於某個人，而是屬於兩個人。”才發現我的理解是有偏差的。但是我覺得我的理解方式也有一定的高效性，這樣的結對編程方式是可取的嗎？
第十七章
1.如何區別對待這個問題下：“盡管兩個團隊的貢獻和管理水平有很大的差別，這兩個團隊的經理都得選出10%的成員作為最差的成員。”
問題：
對於好的團隊，既然這是一個很艱難的決定。可以只分為兩部分，突出的前20%和剩余的80%嗎？
我的看法：
我認為對於一個好的團隊，不是必須要把表現同樣不錯的成員歸到10%中。這個划分和評價應該更靈活些。如果成員表現的都不錯，我覺得可以只采用表揚獎勵優等的20%的方法。在這種情況下如果非要選出差的10%，可能會影響團隊的團結度，影響團隊隊員間的關系。同時會打擊那10%成員的積極性。我認為一個真正優秀的團隊，每個人對自己的定位和待遇都會呈現一個滿意的狀態，都是為了項目竭盡全力的付出的。所以在很多情況下，是沒有必要非要選出10%不好的，進行“明顯的不同待遇”的。
2.信任模塊下：“敢於互相分享自己或自己團隊的薄弱環節”。
我的看法：
我非常認同這句話。我認為真正的信任，不是拼盡全力掩飾自己已經察覺到的代碼的缺點，以這種方式讓隊友肯定你的能力和實力，而應該是開誠布公的，坦誠的和隊友一起探討自己代碼或思路中的不足之處，或者整個團隊需要改進的地方。只有能夠客觀理性的分析團隊面臨的問題，整個團隊才能進步和提高，而不是在自己的世界中自欺欺人。
以上就是閱讀完后，我個人的一些感悟和想法，希望能和大家一起討論交流，共同進步。我覺得在之后的結對編程與團隊編程中，如果遇到自己覺得難以解決的問題，可以再一次閱讀這兩章，我相信它會告訴我們答案。