初步閱讀這本書，只是簡單的過了一遍，對比之前的一些理解和做法也做了一些思考
過去我的理解和做法;
過去我將電腦科學和軟體工程簡單的定義為理論學習和動手操作。我認為學習軟體工程最重要的就是會程式設計，但其實任何有關計算機的學科都離不開程式設計，它只是一門基本技能，卻並不是學習軟體工程的核心。《構建之法》書中指出：軟體工程的研究目標（軟體的開發、運營和維護）中都有「人」的出現，這些「人」可以是專案需求的提供者、可以是軟體的開發人員，還可以是軟體的使用者。這一特徵與其他電腦科學的子領域明顯不同。在課堂中，老師也有講到，在公司中工作時，只有三分之一的時間是在寫**，剩下的三分之二的時間都是在進行文案的書寫，我們有必要能使得所有人看懂我們的程式，使用我們的程式。絕大部分時候，衡量我們的軟體的優劣的直接取決於客戶的使用評價。
過去我在編寫**時並不注重變數的命名，往往是越簡單越好，但隨著程式**量的逐漸增多，如果不能通過固定格式的，簡單易懂的命名規則來命名，就會在編寫和閱讀**的過程中不知所云、不知所措，繼而浪費更多的時間。另外，開啟我的eclipse，就會發現專案檔案多而亂，無法通過命名快速找到之前的檔案，沒有將互相關聯的整理在一起，導致再命名專案時不知道命名什麼。
解決辦法;
在網上找一些正規的命名規則，逐漸形成一套自己的命名規則，在每個變數命名後加上注釋。在每一對{}後加上編碼，不省略（）。為每乙個大的專案寫分析報告，分析市場需求，可實行功能、不可實行功能、實現所需時間。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...