通過連續三天的刻苦閱讀，讓我對《構建之法》這本書有了大致的簡單的了解，我覺得這本書對於我們這些以後要進入it領域從事相關事業的菜鳥來說，確實大有裨益。本書作者運用了大量淺顯易懂的日常例子對軟體工程領域相關流程和運用的各種模式方法做出了簡單詳細地描述，幫助各位還沒入行的同學們揭開軟體工程領域神秘的面紗。確實軟體工程涉及龐大複雜的技術知識，不單單只包含電腦科學和軟體兩個專業的知識。閱讀完本書後，自己還有許多問題還沒搞透徹，在此羅列出來，希望感興趣的同學能夠一起研究研究：
1.文章中說許峰雄靠用「蠻力」提高計算機速度的方法戰勝了西洋棋大師，難道真的不能從軟體底層進行突破嗎？我覺得這樣才是實質性的進步。
2.我覺得說中介紹的單元測試和效能分析確實對個人軟體開發能力有很大好處，為什麼在大學裡沒有對學生進行專門的培養呢？
3.難道程式設計用時的平方差必須要越小越好？我覺得有時長有時短時在所難免
4.怎樣用ascii字元對程式進行注釋？怎樣更好地注釋？
5.**複審必須找其他人嗎？達到什麼水平可以自我複審？
6.軟體的團隊模式和流程模式多種多樣，怎樣能夠根據自己的團隊狀況和工程狀況選擇乙個好的團隊模式和流程模式？
7.在軟體工程的敏捷流程中，每個人都要領任務，那麼員工是怎樣領任務或者說領任務的衡量標準？
8.msf敏捷開發模式和cmmi開發模式孰優孰劣？目前哪種模式被廣泛運用？
9.需求分析中，怎樣根據客戶的反饋進行準確的功能定位和分析？
10.有沒有一套確定軟體何時發布的標準？
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...