閱讀第八章所得：
在估計專案用時多少時，往往沒有乙個準確的標準，所以要依情況而定。有些事客觀規律，而不是個人能力決定的，因為人的能力不盡相同。這裡有乙個關於時間花費的經驗公式：y（實際時間花費）=x（對某事件的估計時間）±x（對某事件的估計時間）÷n（做過類似開發工作的次數）。這是在軟體工程師在長期的實踐中摸索出來的。對於乙個龐大的專案來說，「分而治之」更便於開發。
至此，六篇閱讀筆記結束。就只是閱讀了前八章，我就感覺到作為一名軟體工程師是需要具備很多很多的能力和素質，開發專案的每乙個過程都是這麼有講究，每乙個都是有學問的，軟體這方面的知識也是博大精深，還包括了交流的方法等等，就像做人的道理一樣。
個人感受：
1、我過去是怎麼做的（或者我過去看見誰是怎麼做的）：現在都是個人作業，所以，總是會以自己的標準來衡量程式的需求。
2、結合書中所講，說明為什麼這樣不好：這樣，對以後顧客的需求定的不准。
《構建之法》閱讀筆記六
第七章閱讀筆記 msf 微軟推薦的軟體開發方法。msf基本原則 推動資訊共享與溝通 就是盡量做到將資訊共享給團隊的每乙個成員，每個成員都對資訊有較為完整的了解，而且各個討論和決定都要涉及所有的角色，告知所有的人。為共同的遠景工作 就是每個成員心中都有遠景，為了實現遠景而努力，而且每個成員心中的遠景都...
《構建之法》閱讀筆記六
乙個團隊經歷了計畫 設計 開發等階段，達成 完成這一目標，但是軟體生命週期的最後階段往往是最考驗團隊的，不但考驗團隊專案管理水平 應變能力，也考驗團隊的 血型 在穩定階段的初期，團隊只要決定需要修復哪些缺陷，然後團隊成員就會進行必要的設計 實現 測試工作，並簽入 修改。但是，隨著專案進展和發布日期的...
06構建之法閱讀筆記之六
整本書對軟體構建的方方面面寫的很清楚，包括需求，設計，開發，測試，專案管理.等實在無法一時消化，對我們以後的工作有很大的參考價值，至少對於我目前這樣的狀態來說，了解自己要怎麼做，做的方向比要做什麼更重要，本書提供了很多建議和方法，也由此了解到作為乙個軟體工程師，任務清單裡面不僅只有要編好程這一項而已...