從第一章概論中提到，軟體工程要創作足夠好的軟體。
而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開發效率、使用者滿意度、可靠性和可維護性。——p15
而什麼是bug呢？書中明確提出，就是軟體的行為和使用者期望度不一致，當乙個軟體被使用時，使用者希望軟體可以流暢執行並且不崩潰，但這時軟體因為不知名的原因崩潰了，從這方面就用bug可以衡量出軟體的可靠性，可以說這就是乙個bug。
書中也明確提出，並不是沒有bug就是乙個完美的好軟體，就像helloword，永遠不會出錯但它並不能稱之為乙個好軟體。從中又大概了解到乙個好軟體，就是bug盡可能的少，滿足大多數使用者的需求也可以說是期望值。書中定義的bug即軟體的行為和使用者期望值不一樣。
我也產生了幾個問題：軟體並不可能滿足所有人的期望，當它可以滿足大多數人的期望時，而卻總有一部分人認為軟體不合乎自己的期望，這可不可以說是乙個bug？得到的使用者的新需求是不是有價值的，是不是接下來要改進的，且完善後又會不會使軟體冗餘複雜而流失另一部分使用者，修改到什麼程度為止才能算得上乙個好軟體？需不需要對小部分使用者更精緻細化的功能模組需求當作bug進行完善？
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
構建之法 01 書中的1.2.4中dug問題讓我感觸頗深，bug是我們日常生活中常說的乙個詞，哪怕是非專業的人也是隨口說來。但在軟體工程中的bug其實和日常的bug是有很大區別的，我們習以為常的bug就是影響乙個正常軟體執行的錯誤 其實不然，bug真正的含義是 軟體的行為和使用者的期望值不一樣就叫b...