本次內容是《構建之法》第二章的閱讀感受，本章主要內容是講乙個合格的軟體工程師應該具備是能力：
即單元測試，效能分析，個人開發流程（psp）;
在開發過程中，理論上只有乙個導致他變化的誘導因素，乙個模組應該整個都是由這個因素進行主導；用我的理解來說，乙個模組應該只有乙個核心功能，而這個功能模組的負責人應當圍繞著這個模組進行功能的搭建，而不應該多個點側重最後導致軟體模組沒有乙個核心功能來支撐整個系統或者軟體的執行。
此外，在學習過程中，我常常為了功能的多樣化，往往會導致軟體的某個功能並不能做到盡善盡美，甚至出現許多bug的情況，針對這種情況，也許可以試試將系統進行模組的劃分，針對某乙個模組進行核心功能的搭建，可能正如書上所說，軟體工程的核心即為，「將乙個複雜的問題簡單化，將乙個簡單的問題進行步驟化」，這樣乙個軟體的構建就可以進行出來，然後就可以按步驟進行系統的搭建即可。
乙個軟體的健壯性可以從以下的方面進行確定：資料，使用者，例項，需求，和軟體構建。
就比如資料，可能乙個系統，使用者並不會按照你預計的想法進行執行，你要求使用者輸入數字，可能使用者就會輸入字母，甚至漢字，因此，在開發時，我們就需要對這些問題進行考慮，而不能等到問題延續下去。
乙個軟體或者系統的具體開發流程為基本功能，拓展功能，高階功能；此外回歸測試也可以保證質量。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...