一、前言

　　精讀書可以讓人有不一樣的收獲，通過本次閱讀我認識了不少之前從未註意過的問題。第4章中提出了許多編程方面的規範和兩人合作結對編程的階段和技巧，第17章有許多生動的故事來形容“人”“效績”“職業道德”之間的各種道理，並提出了一些令人值得深思的話題，耐人尋味。但其中仍有些許不太清楚，或許也有些不敢茍同的地方。關於個人觀點提出的問題，如下。

二、關於問題

第4章 兩人合作：

“匈牙利命名法”

　　對於代碼規範之前也有涉及，之前提倡的命名法是“駝峰命名法”，因為初次接觸了“匈牙利命名法”這個新名詞所以略有不解，查閱資料後得知命名方式為：變量名=屬性+類型+對象描述，每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。其實之前接觸的“駝峰命名法”也有自己的特點因為使用的變量函數名字一般是帶有對該算法的通俗解釋的，且因為大小寫字母而變得層次清晰，對比起來可讀性很高更容易的在同行之間交流。那麽既然他們都是有提倡的，將來在工作中是否兩者都可以使用,如果現在就要養成習慣那應該是用哪一種比較好適應將來的工作要求呢?

第17章 人，效績和職業道德：

“一個新人能加入一個團隊，團隊領導看重他什麽？”

“所以我們要讓‘蘿蔔快了不洗泥’的人慢下來，這樣能減少他們的危害”

書中提到的只有“知識”“專業技能和職業技能”“投入程度”，而在我看來既然是在團隊之中，是否還缺少了十分重要的一點“團隊意識和大局觀”呢？一個新人擁有豐厚的技能和知識儲備，倘若只是自己成長，會否略顯孤傲呢，畢竟一個復雜的項目永遠不可能是一個人就能夠完成的。另外就是大局觀，團結他人，有余力時幫助同事共同進步的好性情，應該是會更為領導待見的吧。

其中“蘿蔔與白菜”的故事也引起了我的思考，書中最後的解答是偏向了白菜，而否定了蘿蔔，在我心裏留下了些許疑惑，難道蘿蔔這樣一群人就真的是危害一個團體的存在？假如在一個團隊裏，白菜與蘿蔔比較，我們真的應該是更看重高質量完成任務的白菜而去抑制住蘿蔔的速度？在我個人看來應該是不一定的吧，蘿蔔與白菜各有用處，應該是不能一概否定又全部認可。在蘿蔔中也會有好蘿蔔與壞蘿蔔之分，我所理解的好蘿蔔是那種在錯誤中學習並不斷完善自己，提升自己工作效率的技術人員，與一味就知道為速度犯錯的蘿蔔相比，最好區分的特點就是在不斷犯錯中會否不斷修正自己的錯誤，為維護人員和整個工程著想，顧全大局一錯不再二犯或多犯，程序設計越來越有規範和條理。隨著速度的提升工程量的加大，毫無疑問這群蘿蔔在將來必定是無論見識，還是學習能力都會遠超其他人。在程序開發中，即使是對於白菜而言犯錯也是不可避免的，改錯能力有時也會成為一種優勢。另外就我個人所知，太過於中規中矩，按時完成，也可能是一種應付任務的消極狀態吧？很多時候作為程序的開發者維護者，交給自己完成的時間有時也是十分有限的，尤其是維護階段，因為可能成千上萬人正在等著使用，此時好蘿蔔是否更占據優勢呢？所以個人感覺兩者都應該是團隊中不可或缺的吧，只是要合理分析他們的利弊。

精讀《構建之法》第4章與第17章