一、前言
精讀書可以讓人有不一樣的收穫，通過本次閱讀我認識了不少之前從未注意過的問題。第4章中提出了許多程式設計方面的規範和兩人合作結對程式設計的階段和技巧，第17章有許多生動的故事來形容「人」「效績」「職業道德」之間的各種道理，並提出了一些令人值得深思的話題，耐人尋味。但其中仍有些許不太清楚，或許也有些不敢苟同的地方。關於個人觀點提出的問題，如下。
二、關於問題
第4章 兩人合作：
對於**規範之前也有涉及，之前提倡的命名法是「駝峰命名法」，因為初次接觸了「匈牙利命名法」這個新名詞所以略有不解，查閱資料後得知命名方式為：變數名=屬性+型別+物件描述，每一物件的名稱都要求有明確含義，可以取物件名字全稱或名字的一部分。其實之前接觸的「駝峰命名法」也有自己的特點因為使用的變數函式名字一般是帶有對該演算法的通俗解釋的，且因為大小寫字母而變得層次清晰，對比起來可讀性很高更容易的在同行之間交流。那麼既然他們都是有提倡的，將來在工作中是否兩者都可以使用,如果現在就要養成習慣那應該是用哪一種比較好適應將來的工作要求呢?「匈牙利命名法」
第17章 人，效績和職業道德：
「乙個新人能加入乙個團隊，團隊領導看重他什麼？」書中提到的只有「知識」「專業技能和職業技能」「投入程度」，而在我看來既然是在團隊之中，是否還缺少了十分重要的一點「團隊意識和大局觀」呢？乙個新人擁有豐厚的技能和知識儲備，倘若只是自己成長，會否略顯孤傲呢，畢竟乙個複雜的專案永遠不可能是乙個人就能夠完成的。另外就是大局觀，團結他人，有餘力時幫助同事共同進步的好性情，應該是會更為領導待見的吧。「所以我們要讓『蘿蔔快了不洗泥』的人慢下來，這樣能減少他們的危害」
其中「蘿蔔與白菜」的故事也引起了我的思考，書中最後的解答是偏向了白菜，而否定了蘿蔔，在我心裡留下了些許疑惑，難道蘿蔔這樣一群人就真的是危害乙個團體的存在？假如在乙個團隊裡，白菜與蘿蔔比較，我們真的應該是更看重高質量完成任務的白菜而去抑制住蘿蔔的速度？在我個人看來應該是不一定的吧，蘿蔔與白菜各有用處，應該是不能一概否定又全部認可。在蘿蔔中也會有好蘿蔔與壞蘿蔔之分，我所理解的好蘿蔔是那種在錯誤中學習並不斷完善自己，提公升自己工作效率的技術人員，與一味就知道為速度犯錯的蘿蔔相比，最好區分的特點就是在不斷犯錯中會否不斷修正自己的錯誤，為維護人員和整個工程著想，顧全大局一錯不再二犯或多犯，程式設計越來越有規範和條理。隨著速度的提公升工程量的加大，毫無疑問這群蘿蔔在將來必定是無論見識，還是學習能力都會遠超其他人。在程式開發中，即使是對於白菜而言犯錯也是不可避免的，改錯能力有時也會成為一種優勢。另外就我個人所知，太過於中規中矩，按時完成，也可能是一種應付任務的消極狀態吧？很多時候作為程式的開發者維護者，交給自己完成的時間有時也是十分有限的，尤其是維護階段，因為可能成千上萬人正在等著使用，此時好蘿蔔是否更佔據優勢呢？所以個人感覺兩者都應該是團隊中不可或缺的吧，只是要合理分析他們的利弊。
《構建之法》 閱讀（第13章 第17章）
第13章 軟體測試 1.名詞解釋 bug 軟體的缺陷 test case 測試用例。測試用例描述了乙個完整的測試過程，包括測試環境 輸入 期望的結果等 2.bug解釋與例項 1 bug可以分解為 症狀 symptom 程式錯誤 fault 根本原因 root cause 症狀 即從使用者的角度看，軟...
《構建之法》第4章
第四章是關於兩個人合作的概論 大概就是 規範性 複審 結對程式設計 和兩個人的合作的方式技巧 軟體從來不是乙個人的工作，是乙個團隊的作品。在開始之前我們需要先對程式設計有乙個規範性，不然團隊中的每個人只按照自己的思維去 行走，這是不行的。所以我們要準守 的規範性，這樣對團隊以及他人在工程進行中對 的...
讀《構建之法》第4章有感
在 構建之法 第4章中，提及最多的就是 結對程式設計 了，為什麼要 結對程式設計 呢？為什麼這兩個人不各自做各自的事情呢？這樣就可以同時做兩件事了，從某種意義上取得了雙倍的效率，為什麼不呢？你沒猜錯，我就只能提問題，至於解決問題，這個還是從書中捕獲答案吧。在結對程式設計模式下，一對程式設計師肩並肩 ...