閱讀筆記
我在閱讀書籍的時候，大部分都是瀏覽，也許是跟我看的書籍的內容有關係吧，但是，在瀏覽過《構建之法》這本書後，我精讀了它，以下是我在閱讀完1，2，16章後有的想法和問題，希望和大家一起分享和討論。質疑和不斷探索會幫助大家進步。
第一章 概論
引用
軟體團隊要從需求分析（requirement analysis）開始，把合適的需求梳理出來，然後逐步開展後續工作，如設計（軟體架構）、實現（寫資料結構和演算法）、測試，到最後發布軟體
——p3
問題一：需求易變，可否將需求分割成為細密的任務點？
好的軟體，一定會有很好的使用者體驗，不同的使用者對軟體的功能和介面有不同的需求，而在開發過程中，有時會出現需求變化的情況，有些變化甚至可以將整個專案推倒重來。這樣，我們在對需求的實現過程中，任務點分配或許可以幫助軟體提高其本身的可維護性，對於軟體的後續發展也有些許進益。
引用
什麼是bug呢？簡單的說，軟體的行為和使用者的期望值不一樣，就叫bug，是否是bug，取決於使用者、開發者的不同角度。
——p16
問題二：當使用者的期望值和軟體的優化方向起衝突時，應當如何抉擇？
業務方面與使用者方面之間產生了衝突，如果我們將業務層面的需求簡單考慮之後，我們再進行對使用者方面的思考，這個時候，我們所面對的一些使用者需求，有時候很容易和業務目標之間有會衝突，當我們圍繞使用者期望為中心去設計時，業務目標往往不能很好的達成，而實際上，正確的思維方式應該是，以業務目標為基準去推導使用者的行為，當這個行為和使用者目標相違背時，我們應該想辦法把使用者不喜歡做的事轉化為和使用者使用動機相關的事情，引導他完成。
根據我所查閱的資料顯示：
從開發者的角度，解決方案圍繞四個點進行：
1、 尋找業務和目標的關聯
2、 確定相對平衡的方向
3、 提供多個設計方案
4、 最終方案呈現
第二章 個人技術和流程
引用
單元測試必須由最熟悉**的人（程式的作者）來寫。**的作者最了解**的目的、特點和實現的侷限性。所以，寫單元測試沒有比作者更適合的人選了
——p25
問題一：單元測試一定要作者自己寫嗎？
查閱了部分資料後，發現了開發人員和測試人員都可以寫單元測試；對於一些測試人員供給不足的小公司，要求開發人員寫單元測試，而對於一些大公司，常常設定有測試部門進行。開發人員對**最熟悉，而且開發技能也強，開發自己寫單元測試效率上和覆蓋率上都比較高。而且單元測試有時候需要開發對**進行部分重構才方便進行，開發自己做這些重構也比較順手。但是開發人員可能會因為業務**的繁重而顧不及單元測試的書寫，如果只是寫單測對軟體的進益幫助不大。測試人員寫測試有比較好的測試思想，可以更好地保證用例的覆蓋。而且通過寫單測測試能更好地了解具體**結構、流程，對於後續的業務測試也有利。但是測試人員對**沒有開發人員熟悉。
具體怎麼選擇就是個問題。
第十六章 it行業的創新
引用
迷思之一：靈光一閃現，偉大的創新就緊隨其後
迷思之二：大家都喜歡創新
迷思之三：好的想法會贏
迷思之四：創新者都是一馬當先
迷思之五：要成為領域的專家，才能創新
迷思之六：技術的創新是關鍵
迷思之七：成功的團隊更能創新
迷思之八：創新者都是冒險家
——p340-p354
問題一：it業創新究竟需要什麼？
對於軟體開發人員來說，創新是非常重要的。在這個需要創新的時代，無論什麼行業都需要創新。但是在如今的時代，進行前無古人的創造難度很大，在某些情況下我們需要在前人的基礎上進行一定的創新。
有時候，創新並不是能被所有人接受的，每個新事物的出現都需要一定的時間才能被人們接受。如果我們有好的想法，就要搞清楚我們能從這個想法中得到什麼，現在自己具備的條件，以及與這個時代是否相容。否則好的想法也不能付之實踐。
創新者通常都會很成功，但是這些人一般不會是先行者。在it行業中，系統專案或者其他軟體是經過不斷的創新開發才得以完善。大部分人會覺得自己不是這一領域的專家人才，而不願意去嘗試，但是蒂姆-伯納斯李就實現了，他是物理學家，實現了http協議通訊。
創新並不是必須要乙個非常優秀的團隊才能完成的事情，如果乙個軟體開發團隊有技術，有耐心，有團結心，有嘗試的勇氣，未來有無數種可能性，創新也有無限種**，他們也可以成功。
《構建之法》問題與思考
第一章 概論 1.引文 乙個軟體或者服務要有人買就得找到顧客。顧客有各種需求，有些靠譜，有些不靠 有些容易做到，有些難以做到。軟體團隊要從需求分析開始，把合適的需求梳理出來，然後逐步展開後續工作。問題 在開展專案之前的需求分析階段，各種分析資料是軟體團隊自己去蒐集還是團隊從其他途徑獲取？如果軟體要求...
《構建之法》1 2 3章思考與感想
這學期，我們開始學習一奔叫做 構建之法 的書籍，剛開始接觸，覺得就像霧裡看花一樣，所涉及到的很多概念都不懂。隨後在這個週末，我靜下心來，細細閱讀，終於發現這本書並沒有想象中那麼枯燥無味，而是一本值得我們去學習，去思考的好書。困惑 第一章1.2節 軟體工程究竟是什麼？書中說到，軟體工程是把系統的 有序...
讀《構建之法》第1 2 3章的思考與感悟
構建之法 這本書和我以往的教科書都不一樣，這本書不再一味介紹課本的概念知識，而是加入一些生動的例子，這樣更能讓人了解 掌握 記憶，對這門學科有更深的了解。有了這本書，這門學科不再枯燥無味，而是有趣的。第一章1.2節 困惑 軟體工程是什麼，定義說軟體工程是把系統的 有序的 可量化的方法應用到軟體的開發...