《構建之法》01
書中的1.2.4中dug問題讓我感觸頗深，bug是我們日常生活中常說的乙個詞，哪怕是非專業的人也是隨口說來。但在軟體工程中的bug其實和日常的bug是有很大區別的，我們習以為常的bug就是影響乙個正常軟體執行的錯誤**，其實不然，bug真正的含義是：軟體的行為和使用者的期望值不一樣就叫bug。書中舉到的例子很有代表性，乙個使用者根本不需要的功能是bug還是feature，乙個使用者潛在需要的功能是bug還是feature。
1.過去的做法：過去我總是覺得bug就是**中的標紅的地方，其實不然，一切不符合使用者要求的地方，哪怕是完美無誤的程式，都算是bug；
2.不好的地方：這種想法是不好的，僅僅侷限於**中的問題是不夠的，這是外行人看的東西，我們搞軟體的要放大眼光，使用者的最終體驗要求所涉及的bug才是我們應當重視的；
3.改進的方法：bug的這種思考就牽扯到了軟體工程中的「足夠好」：我們在軟體工程中要做到三點：1、研發出符合使用者需求的軟體。2、通過一定的軟體流程，在預計的時間內發布足夠好的軟體。3、能證明所開發的軟體是可以維護和繼續發展的。做到這三點就是初步學會了軟體工程。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...