這幾天我都在讀《構建之法》第四章和第十七章，看的比較緩慢也比較認真。根據精讀的要求和個人看書的習慣，我總共讀了三遍，第一遍是大致瀏覽了一遍內容，第二遍是靜下心來圈畫、標註疑惑內容，第三遍是重新瀏覽了一遍並解決了一些疑惑。這次作業是讓大家精讀教材後提出問題，具體請看以下內容。

第四章

問題一：第一小節是講“代碼規範”，在“4.2.4斷行與空白的{ }行”這一部分，最後作者選擇的格式是“每個‘{‘和‘}‘都獨占一行，即格式D”。其實我個人對這個做法是不認同的。

我覺得“格式C”好，既有“{”和“}”來判斷程序結構，又很清晰。“格式D”相較於“格式C”而言，“{”和“}”各自獨占了一行而且“if”和“else”單獨也成一行，在我看來這樣占行數太多，浪費行數且不說並且會增加程序運行的時間，這也是其他開源網站代碼為何代碼行數盡量少的原因之一。我認為“格式C”已經很完美了，沒有必要再寫成“格式D”。

問題二：書中P66頁提到了“匈牙利命名法”，也舉了兩個例子，但是沒有具體說明概念，所以究竟什麽是“匈牙利命名法”呢？

為此，我特地百度了一下，百度百科的定義是：匈牙利命名法是一種編程時的命名規範。基本原則是：變量名=屬性+類型+對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。要基於容易記憶容易理解的原則。保證名字的連貫性是非常重要的。

問題三：在“4.2.9註釋”這一部分，作者說“不要註釋程序是怎麽工作的（how）”。其實我個人對這個做法是不認同的。

我認為還是要解釋how，不管是對於代碼“小白”還是“大佬”來說，其實一定程度上還是有這個必要的。因為對於“小白”

問題四：在“4.3.2 goto”這一部分，書中說“函數最好有單一的出口，為了達到這一目的，可以使用goto。”，可是我記得很清楚C語言老師說少用goto，為什麽書中強調用goto呢？

為此，我上網找了一下，網上風評不一，我截圖如下：

其實，看了之後，也不是特別理解。

第十七章

問題一：書中P402頁提到“劃分等級和公開刺激的做法”不是有效的，書中只說了三種內部驅動因素，那麽我想問的是什麽是有效的呢？另外，書中評判了“體力勞動（獎金越多，結果越好）”而“創造性思維活動（獎金越多，效果相反）”，這一點我是不贊同的。

對於什麽是有效的做法，我沒什麽資歷，自然也回答不上來。對於“體力勞動（獎金越多，結果越好）”而“創造性思維活動（獎金越多，效果相反）”這一點，我想說的話很多，我覺得軟件工程師做的是創造性思維活動需要內部驅動因素來討論效績沒有錯，可是關於金錢報酬這一塊我不是很認同作者的說法。我覺得軟件工程師需要一定的獎金作為報酬，同時為了個人利益或者個人動力以及公司效益或者公司發展，一定程度上增加獎金數我認為起到的是促進作用而不是消極的。

問題二：書中P408練習與討論“2.在團隊中會不會出現‘劣幣驅逐良幣‘或者‘不敢犯錯誤‘的現象”中舉的例子是“NBA球星科比投籃次數不中次數是世界第一......問應不應該懲罰？”，可能大家各有所思所想，但我認為是不必懲罰的。

我換了一下這個問題的問法，應該大概意思是“在一個項目中，一個很厲害的人犯了很多基本知識點的錯誤，要不要接受團隊的懲罰？”。其實在我看來，是沒必要懲罰的。首先，這個人是技術大牛，缺他不可。其次，倘若少了這樣的厲害人物，團隊如何出彩？再就是是人都會犯錯，怎麽能夠因為一些小失誤就嚴加懲戒呢？最後我覺得只要不是什麽大bug出了什麽大事件，不管團隊中是大佬還是一般成員犯了錯，我們都應該予以諒解，不要過於嚴苛。

我讀《構建之法》四、十七章