起初我讀這本書，就是「讀書」，一遍看過去，腦子裡就只是被動的接受資訊，一點「感覺」都沒有，更不用談提出問題。個人對於這類專業書籍的閱讀沒有經驗（《構建之法》不像是一本課本…也不像平時的一些碎片化閱讀的讀物…），於是我就用了一種十分笨拙的讀書方法——每讀一段問自己這段在講什麼，每讀小節問自己這節在講什麼，每讀一章問自己這章在講什麼。這樣閱讀，很累，我不得不將每一部分記下來（為了在概括的層面上繼續概括），在概括的時候我發現自己又忽略了很多細節，讀完一章之後，只能在腦海裡留下一句話（很多細節被犧牲掉了…）。比如第一章，我給自己的一句話就是「軟體開發就是在各種約束之下做出妥協，並盡全力做到最好」。但實際第一章還包括許多其他一些有關軟體工程的知識（軟體企業、軟體與計算機的區別等等…），但我很難做到總結出乙個全面的知識（我在概括的同時也略去了很多）。我在讀這本書的第乙個問題，實際上是如何真正的去讀懂這本書，如果無法理解而只是在表面停留也提不出很多深刻的問題（我很認同一位學長的觀點：如何去判斷乙個人是否讀懂乙個專案、一本書、一門技術，最關鍵的點就在於他是否能對其中的內容提出問題）。
關於第一章的第乙個問題，並不是我在讀書的時候意識到的（很不幸，無論我怎麼做，我也無法在讀書時提出乙個詳細的問題…），而是在閱讀其他一些東西時發現了衝突。
在書的p7有這麼一段話：
「我們無法想象，某個商用型號的發動機在飛行時發現問題，最初的設計師會自己爬到引擎中敲敲打打，然後鑽出來說：『繼續飛吧，我搞定了。』然而，在軟體行業中，很多軟體工程師往往以這樣的行為而自豪。」其他有關第一章的問題我覺得大都因為第一章是「概述」的關係，我想在後續的教學中應該都可以得到解答。
有關第二章，它不像第一章那樣資訊量巨大，我對這章最初的困惑都是**於c#和vs，但都影響不大。第二章介紹了身為乙個軟體工程師應具備的一些東西，學會對自己的模組進行測試、效能分析，對自己的開發過程進行改進。
我疑問的是，單元測試為何或者怎麼去幫助他人理解我開發的模組的。在我當下的工作中，我需要去理解別人開發的模組，希望藉此可以加快自己的進度。然後我還有乙個疑問：單元測試是否有必要寫的複雜到（或者說具體到）去測試我的模組不能幹什麼（我在**清單2-4中看到了類似的**）。我猜想這算是去測試使用者的極端行為（我不知道這種行為的正確稱呼），但這些測試都是我們在專案完成後上線前夕進行集中測試時做得事——往往都是直接在前端上進行測試，而不是寫單獨的測試例。
第十六章，講創新。我覺得在缺乏前面十幾章鋪墊的情況下（我只按課程要求讀了這本書），我讀起來就像看故事。講實話，我提不出什麼問題，任何乙個論點下都是完美的論述過程來支撐（至少我挑不出刺）。我既沒有創新的經歷，也沒有創新的想法，最多也只可能想做到書中提到的線性創新（實際上我有這樣的專案）。我只能說一下我對創新的想法。曾經參加一次學校組織的創新講堂，由兩位來自賓州大學的教授給我們講創新。他們更多的提到的是思維模式，如何去多角度思考問題，如何培養這種思維模式，如何去發現問題，如何拆分問題去解決問題（這點很受用，我發現在開發時這點很棒）。當然他們講的也與本書有所重複，例如產品被使用者接受的週期和產品研發的週期也有所提及，但他們更加注重思維這方面。而本書十六章在我的理解中似乎更多的是從工程角度、商業角度去闡述如何不僅僅是做到創新，而是做到「innovate to win」。雖然同樣很受用，但這部分我個人覺得並不是很適合現在的我們閱讀，它更適合那些剛剛開始創業的迷茫者。的確，只有活下去才能繼續創新，但如果連創新的門都無法進入，那也無從談起創新了。這部分是我在讀完十六章，在寫下這篇博文時突然想到的東西。
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...
《構建之法》讀書筆記
乙個軟體除了穩定 功能強大，使用者體驗也很重要。程式開發人員和測試人員在強調其功能和效能的同時，還有一點很注重的就是使用者體驗。在我們學習的最初階段老師們就強調對於軟體開發來說使用者體驗的重要性，無論軟體還是硬體，都有很多功能部件，各個部件還要郵寄的結合起來，才能滿足使用者的需求。其中有一點特別，就...
構建之法讀書筆記
在上一次，我讀了大道至簡，在大道至簡中，我理解了軟體開發所需要的是簡化與便捷，這是軟體工程需要思考的地方。而在構建之法中，我學到了軟體開發中更符合我的問題的東西。書中說，軟體工程師的成長分為四個階段 玩具時期，愛好者時期，探索者時期，行業時期。在這四個時期中，我處於玩具時期。還沒有掌握最基本的東西。...