第四章

　1、原文；“函數最好有單一的出口，為了達到這個目的，可以使用goto.只要有助於程序邏輯的清晰體現，什麽方法都可以使用。——P69”

　　 問題：關於goto，我記得老師講過，這個在編程中是盡力避免的，所以我在之前並沒有了解過它。本書卻建議用，這讓我產生了困惑。

　　 我的看法：goto語句它可以不受限制的靈活跳轉，這樣程序員在使用goto語句的時候就很容易因為跳轉而略過了一些關鍵語句。但是它能從多重循環體中跳出，用不著寫很多次的break語句。我查了一些資料，發現自從提倡結構化設計以來，goto 就成了有爭議的語句。我閱讀了一些同學的博客，他們對goto的作用及利弊條理清晰的列了出來，在這裏我就不詳細的列出來了。但是在我查資料的過程中，發現所有的資料最後都寫了建議慎用，少用，但沒有一個回答是不要用。我又仔細地讀了書中的這段話，發現是我誤會了作者的意思，其實他的這句話也不是我之前所理解的提倡我們用goto.而是為了程序邏輯的清晰體現可以用。這和我們所提倡的慎用是沒有矛盾的。

　2、原文：“在結對編程中，程序各方面的質量取決於一對程序員中各方面水平較高的一位。這樣對編程有如下好處：...... 。結對編程惡意取得更高的投入產出比。——P79”

　　“結對編程讓代碼不斷地處於復審的過程，程序員能夠不斷地審核，及時發現問題，避免吧問題帶到後面的階段去。”

　　 問題：結對編程真的利大於弊嗎？

　　 我的看法：在結對編程中，程序各方面的質量取決於一對程序員中各方面水平較高的一位，這個我也深以為然，但是對應的水平高的那位同時也承擔了更多的編程任務，同時還可能要去教夥伴編碼，在項目中付出大量的精力。所以我覺得可能在團隊中產生矛盾，避免矛盾的方式大概就是在選擇夥伴時找水平差不多的，最好技術和個性能互補，還要合得來。這又產生了另一個問題，這樣多要求的夥伴找得到嗎？我覺得是比較難得。而且要求技術水平不要差太大，那麽水平高的那位對程序質量的決定性就不是那麽強，那這樣豈不是違背了結對的初衷？有浪費時間的嫌疑。而且結對編程不能替代代碼評審。雖然結對編程對代碼的審核程度比代碼評審細致的多。但兩個結對的人有明顯的思維趨同性，從而忽略同樣的問題或者犯下同樣的錯誤

第十七章

　1、原文：“關於代碼量，作者在上課的時候給同學講了這個故事：......代碼量等於樹葉量，當作如是觀。——P398”

“蘿蔔與白菜——P403”

　　 問題：代碼量難道就是毫無用處的樹葉嗎？。

　　 我的看法：這個我是有疑惑的，因為我認為，代碼量是程序員的基礎，不管是評定效率還是代碼的有機結合解決客戶需求，都要有大量的代碼作為基礎。當然我說的是認真敲出的代碼。我覺得一個高效的程序員、一個大牛。他的成長過程肯定有大量的代碼做基礎。可能是因為我還在學習階段，在成長的階段，身邊厲害的同學都是比別的人敲過更多的代碼。所以我認為一個程序員他敲的代碼多收獲和經驗自然會更多、bug會更少。就像17.7蘿蔔與白菜所說的蘿蔔，我不懂為什麽作者會認為他未來每天都忙忙碌碌敲很多代碼，做很多工作，然後沒有一點進步，還是會繼續讓自己的代碼有那麽多缺陷。我恰恰認為他會在缺陷在汲取教訓，進行改正。而且他勤勞又熱心，在團隊中很有價值。

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