《構建之法》當教材真的很棒，沒有那麼死板，更多由故事引出，吸引眼球，讓我這麼乙個不甚喜這門專業的學生能夠看得進書，在這裡先感謝鄒欣老師，真的十分感謝。
對於第一、二、十六章中講述的內容提出問題，其實我更多的是有一些不成形的看法，可能有些幼稚，若有不妥冒犯之處，還請各位老師見諒。
第一章 概論
乙個心理暗示性的例子的利弊？如何判斷需求的是否應該被重視？如何理解bug？
第一章第一小節（p7）中舉了個例子：
如果一架民用飛機上有需求，使用者使用它的概率是百萬分之一，你還要做這個功能麼？你會選擇：1.根本不考慮 2.如果沒時間實現這個功能，就算了 3.做了，但是不用告訴使用者 4.做了，而且不厭其煩地告訴使用者如何使用 你會如何選擇呢？
我當時選擇了第二項，因為我覺得乙個不重要的可做選擇的需求應該視情況而決定存在與否，然而我沒想到謎底是飛機的安全功能。看到謎底時我有些驚訝，第一時間懊惱自己怎麼能忽略這麼重要的一點，但後來，我仔細一想，我覺得其實問題本身有一定的誤導性，或者說，這個問題帶有一定的心理暗示作用。
對於心理暗示，《心理學大詞典》上是這樣描述的：「用含蓄、間接的方式，對別人的心理和行為產生影響。暗示作用往往會使別人不自覺地按照一定的方式行動，或者不加批判地接受一定的意見或信念。」人的判斷和決策過程，是由人格中的「自我」部分，在綜合了個人需要和環境限制之後做出的。這樣的決定和判斷，我們稱其為「主見」。[1]而在問題中「百萬分之一」、「還」這樣的字眼就存在著一定的重複強調的心理暗示——這個需求不被重用。在這種情況下，我做出了錯誤的判斷。我覺得在特意的誘導下導致學生做出錯誤的判斷並不能真正體現學生的想法，如果一開始即提出是飛機的安全功能，相信所有學生幾乎都能夠選擇第四項。誠然這種提問或許能提高同學在下次考慮問題時的全面性，所以我也無法說出心理暗示性提問的利弊關係。
回歸需求，其實我自己對需求是分成三種性質，一種是服務性，一種為功能性，一種即安全性。毫無疑問，安全性為重中之重，所有需求都需要服從於它，而功能性則為滿足使用者所需的合理的功能，服務性則是在安全性與功能性的基礎上加以潤色，使之更貼合大眾的使用。安全功能自然屬於安全性，所以這是無需考慮，必須要完成的需求。而比如在飛機上提供wifi服務這種服務性的需求，我相信如果可以，這個需求一定被70%的乘客所喜歡，但在目前的情況來看，這個需求威脅到安全性問題，所以這種需求則應該為安全性需求做出讓步（我希望這不會又成為乙個暗示性的選擇題）。而這個需求屬於哪種性質，不應該單看它使用的概率，更應該結合它的本質以及可能帶來的後果，安全功能的使用概率雖小，但它本質是人身安全，後果可能讓乘客失去生命，所以它應該是第一考慮因素。同理，在程式遇到異常，需要儲存使用者的資料，若無法做到全部保留，我們應該做到保留最重要的資料，正如面對危險時，安全遠比身外之物重要一般，而這種做法需要在使用者輸入資料時，便處理好該資料是重要資料還是無關資料。
第一章的最後（p16）對bug的解釋：
什麼是bug呢？簡單地說，軟體的行為和使用者的期望值不一樣，就叫bug。是否是bug，取決於使用者、開發者的不同角度。
是指在軟體執行中因為程式本身有錯誤而造成的功能不正常、體驗不佳、宕機、資料丟失、非正常中斷等現象。是指電腦系統的硬體、系統軟體（如作業系統）或應用軟體（如文字處理軟體）出錯。[2]
第二章 個人技術和流程
單元測試如何清晰地表達某一「單元」要做的事以及它不能做的事？
第二章第一小節（p25）中阿超的話：
如果你寫的模組會有不同的人，在不同的時間使用，那你最好把你這一「單元」要做的事，以及它不能做的事，用單元測試清晰地表達出來。同時，單元測試也能幫助程式設計師記錄這個模組的歷史和設計變更的理由。我不曾學習過c#和vsts,雖然聽說過單元測試但因為興趣關係並不曾進一步了解，以至於在看這一章的時候懊悔異常。由於知識的匱乏，我對於書中**的整體作用與單元測試的結果領悟不夠。我平時除錯**時，一般是在myeclipse中執行之後看給出的報錯，之後依次按行除錯。我初步感覺，單元測試的功能與我這種方式相似，不過更加系統，便於團隊合作。但如何從執行結果清晰地表達出某一「單元」要做的事以及它不能做的事？
第十六章 it行業的創新
專業對創新有沒有影響？
第十六章第一小節（p346與p353）中兩個迷思：
迷思之一：靈光一閃現，偉大的創新就緊隨其後。迷思之五：要成為領域的專家，才能創新。阿基公尺德與牛頓的頓悟源於之前深厚的基礎積累，而蒂姆·伯納斯-李以物理學家的身份提出了利用超文字實現方便的資訊共享和更新。那麼，專家的身份到底對創新有沒有影響呢？我覺得應該有一定影響，雖然非專家的「門外漢」身份或許能站在使用者的角度簡單的提出一些迎合使用者口味的點子，但是點子的實現需要專業理論與技術的支撐，單靠想是遠遠不夠的。創新是成品的思想，而不是腦中的空想。唯有把想法實踐出乙個受人歡迎喜愛的成品，那才是創新，而實踐便需要專業的基礎積累。故，我覺得專業對創新是有影響的，它在靈光一閃而過之後給予雄厚的技術支援，專業會讓創新更快現世。
我對於《構建之法》提出的小問題與看法也就基本這麼多了，感謝各位老師和同學能看到這裡，聽我囉哩吧嗦了這麼多門外漢的看法，不足之處希望大家多多提點。
小小的疑問和小小的想法
1.事情交與你手，是否應該盡職盡責？大部分人說，你肯定要盡職盡責，少部分人會說這個可以不。我也一直認為應該盡職盡責，但是部分原因導致不會努力去做，如下所述 a 此事責任權是否在於你 如果我做這件事完全不用承擔任何責任，那我根本不會去努力去做，做了之後沒有任何感覺，做與不做的區別在於，少了參與做此事的...
小小的感悟
假期或許真的是乙個人頹廢的開始 這個小假期著實讓我頹廢了三天！回想在沒有放假的時候，自己總是在很早就起來，並開始自己的工作 但是，這幾天卻是一種頹廢，看 睡覺 之前自己規劃著來做乙個小型的專案，主要是對檔案的一些操作 例如 動態讀取檔案裡面的資料 建立檔案 寫入資料等相關的檔案操作。或許規劃就是指導...
小小的總結
知道了f12是重新命名的快捷鍵，shift ctrl n是建立新資料夾的快捷鍵。知道了乙個c語言程式包括哪些部分 標頭檔案 include主函式入口main 花括號 明白了建立場景不是建立資料夾，而是建立scene，將它重新命名為game，用於儲存遊戲。錨點是乙個影象本身方塊與本身方塊的距離。回憶了...