「軟體工程講的淨是一些奇妙玄幻的概念，拗口的專業名詞加上紛繁的複雜的流程」
軟體=程式+軟體工程（軟體企業=軟體+商業模式）
軟體開發的不同階段：玩具階段→業餘愛好階段→探索階段→成熟的產業階段
軟體所具有的特殊性：複雜性、不可見性、易變性、服從性、非連續性。
重要的單元測試：有效解決程式設計師對模組功能的誤解、疏忽或不了解模組的變化之類的問題，使自己負責的模組功能定義盡量明確，模組的質量得到穩定的、量化的保證。
好的單元測試的標準：在最基本的功能/引數上驗證程式的正確性；單元測試必須由最熟悉**的人（程式的作者來寫）；單元測試過後，機器的狀態保持不變；單元測試要快（乙個測試的執行時間是幾秒鐘，而不是幾分鐘）；單元測試應該產生可重複、一致的結果；獨立性——單元測試的執行/通過/失敗不依賴於別的測試，可以人為構造資料，以保持單元測試的獨立性；單元測試應該覆蓋所有**路徑；單元測試應該整合到自動測試的框架中；單元測試必須和產品**一起儲存和維護
單元測試的基礎上能夠建立關於這一模組的回歸測試，目的是：驗證新的**的確改正了缺陷；同時驗證新的**有沒有破壞模組的現有功能，有沒有regression。
個人感受：以前敲**只是瞎胡亂搞，老師說要弄什麼就弄什麼，說怎麼弄就怎麼弄，或者看別人的來弄，很多時候都不太懂基本的流程，導致十分盲目。程式流程圖很重要，之前也沒注意過，還有，抄**不只是抄**。要解決這個問題，首先要多敲**，就算是抄別人的也要先研究流程圖，在盡量手打一遍，不要只會複製貼上。以前還有乙個不太好的地方就是總想著從頭到尾全部手動打出來，在一些小地方還好，不過要是稍微做一些大一點的專案就會出現效率低下的嚴重問題，這是乙個很大的問題，在這裡就體現了靈活套用模板的重要性。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...