今天我閱讀了《構建之法》4-6章。有許多的感悟。
以前程式設計序總喜歡亂命名變數，覺得自己看的懂就行了。但讀完構建之法第四章。我知道了程式是給別人看的，然後那只是程式比較簡單而已。如果乙個程式過於龐大，而變數的命名有沒有實際的意義，估計連程式設計者本身也看不明白了。我以後程式設計命名變數的時候一定要有實際意義。
以前認為程式設計師就是要乙個人做出一款軟體。但我讀了構建之法第五章以後。我明白了是乙個軟體團隊來做一款軟體。有程式設計的，有設計介面的，還有後期維護的等等。做軟體不是乙個人的事，我們以後做軟體的時候一定要積極的融入自己的團隊。
以前認為做一款以前沒人做過的軟體就是乙個軟體工程師最大的成功。當我讀了構建之法的六章以後。我就在想乙個問題，要是做出來的軟體沒人用怎麼辦呢?這還叫成功嗎？這不叫成功。做軟體主要是給人用的。沒人用就不叫成功。所以說我們做軟體之前一定要做充分的調研，了解客戶的需求。從而做出能讓使用者滿意的軟體。
02《構建之法》閱讀筆記02
個人感受 過去我的做法 1 以前每個部分都是分開各做各的，做好自己的事情就好了 不需要管其他的。獨立開發，想做什麼做什麼，只要實現布置的任務就行。這樣做的缺陷 無法做到團隊快速開發，很難提公升速度。問題解決方法 1 要自己挑選任務 每次sprint結束之後，還要總結不足，提出改進，並且自己要實施這些...
構建之法閱讀筆記02
第二章的開頭就給我講出了單元測試的概念和效果，單元測試可以使自己父子的模組功能定義盡量明確，模組內部的不會影響其他模組，而且模組的質量能得到穩定的，量化的保證。還舉例了小飛寫單元測試的例子，讓我們隊建立單元測試主要步驟印象深刻，建立單元測試的主要步驟 1.設定資料 2.使用被測試型別的功能 3.比較...
構建之法閱讀筆記02
今天看了第六章敏捷流程，在裡面我看到了衝刺執行任務中的每日例會，在這裡身份的類似於主人暑假給我們布置的任務和發表部落格的要求，其中這裡面有三條內容，分別是我昨天做了什麼，今天做了什麼，在其中又遇到了什麼問題。這個寫問題只有在衝刺階段真正的做了，用心的去解決了，才會真的有收穫 相反這些流程也會流於形式...