*第四章 兩人合作

問題一：4.2.9註釋

　　“另外，註釋（包括所有源代碼）應該只用ASCII字符，不要用中文或其他特殊字符，否則會極大地影響程序的可移植性。”

我的問題是：

　　自己寫的註釋自己可以理解，但如果別人要維護你的代碼，怎麽才能確保別人也一定能看懂呢？我現在註釋總是要用中文，很不習慣用ASCII字符；但是我還是不太懂，自己註釋的自己感覺大家都能看懂，但有人或許就是看不懂怎麽辦？還有就是我感覺中文註釋便於理解，如果非要用ASCII碼的話，是不是更加不便於理解呢？

問題二：goto

　　“函數最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程序邏輯的清晰體現，什麽方法都可以使用，包括goto。”

我的問題是：

因為以前的C語言老師告訴過我們一般情況下不可以用goto語句，說那樣子很容易造成程序混亂，然後在這本書裏頭老師寫道只要有助於程序邏輯的清晰體現，什麽方法都可以使用，包括goto，我不是很理解。

　　於是，我上網百度了一下，林銳在<<高質量c/c++編程>>裏面是這樣說的:

　　“首先，由於goto 語句可以靈活跳轉，如果不加限制，它的確會破壞結構化設計風格。其次，goto 語句經常帶來錯誤或隱患。它可能跳過了某些對象的構造、變量的初始化、重要的計算等語句，例如：goto state;

　　　　　　　　　　　　　　　　　　　　　　　String s1, s2; // 被goto 跳過

　　　　　　　　　　　　　　　　　　　　　　　int sum = 0; // 被goto 跳過

?

state:

?

　　如果編譯器不能發覺此類錯誤，每用一次goto 語句都可能留下隱患。很多人建議廢除C++/C 的goto 語句，以絕後患。但實事求是地說，錯誤是程序員自己造成的，不是goto 的過錯。goto 語句至少有一處可顯神通，它能從多重循環體中咻地一下子跳到外面，用不著寫很多次的break 語句。就象樓房著火了，來不及從樓梯一級一級往下走，可從窗口跳出火坑。”

我懂得了鄒欣老師的意思是：並不是主張多用goto，而是該用的時候用好goto語句。

摘抄很喜歡的一段話：

結對編程是個漸進的過程，有效率的結對編程不是一天就能做到的。結對編程是一個相互學習、相互磨合的漸進過程。開發人員需要時間來適應這種新的開發模式。一開始，結對編程很可能不比單獨開發效率更高，但是在度過了學習階段後，結對編程小組的開發質量、開發時間通常比兩個人單獨開發有明顯的改善。

　　我覺得老師說的很對，沒有哪一次合作是一蹴而就，一下就可以達到最高效率最高境界的，只有慢慢磨合慢慢適應才可以逐漸將這種模式的優勢體現出來，同時也要註意很多情況下是不需要用到結對編程的，這也很考驗團隊的判斷力。

*第十七章 人，績效和職業道德

　　“例如，在大家做任務估計的時候，那些給出非常樂觀估計的成員會不會產生無形的壓力，讓一些實事求是的團隊成員不得不調整他們原來比較靠譜的估計，最後導致整個團隊的估計都是過於樂觀，客觀（包括比較保守和悲觀）的估計都消失了？或者，在工作中太看重失誤，懲罰失誤，導致無人敢冒險？請看這個例子：NBA球星科比的投籃不中次數已經是歷史第一，超越了大部分NBA球員的所有投籃數，這麽多投籃不中，應該懲罰麽？如果要嚴厲懲罰的話，科比，或者球隊會有更好的成績麽？” 這是老師在書中向我們提出的問題，以下是我對這個問題的看法：

　　書中第十七章前面提到一個團隊需要的是信任，並且這種信任是指：“我信任大家做事的出發點都是為了團隊的共同目標，每個人的水平、經歷、性格特點都不同，我不是完美的，當我犯錯誤，或者展現我性格中不成熟的地方的時候，我信任我的同事會幫助我，但不會指責我的動機，或其他內在屬性。”我覺得一個團隊能真正信任內部成員的話，應該會很願意提出自己的意見，因為大家都是在為整個團隊考慮，即使有不同的意見，大家都可以各抒己見，從而討論出最優解，就不會存在怕說錯話而不願意提出自己中肯的意見。並且，領導團隊應該創建一個和諧進取的工作氛圍，允許大家犯錯誤，畢竟人無完人，領導者應該鼓勵支持每個人表達自己的意見，這樣就不會出現不敢犯錯誤的現象。科比雖然是不中次數最多的人，但他是NBA最好的得分手之一，生涯贏得無數獎項，突破、投籃、罰球、三分球他都駕輕就熟，幾乎沒有進攻盲區，單場比賽81分的個人紀錄就有力地證明了這一點。除了瘋狂的得分外，科比的組織能力也很出眾，經常擔任球隊進攻的第一發起人。另外科比還是聯盟中最好的防守人之一，貼身防守非常具有壓迫性。由此可見，光憑一點是無法對一個人做出準確評價的，因為一點太片面了，這也告訴我們對團隊成員的績效評估應該從多方面考慮，而不只憑單方面對人下定義。

以上便是我讀《構建之法》第四、十七章的看法，謝謝老師的耐心閱讀~

讀《構建之法》第四、十七章有感