很長世間以來我對于專業書的印象一直都是覺得就是一堆知識知識整齊的排列在書上，很友善也有些許無趣。《建構之法》卻讓我對于專業書的整體想法有了不同的看法。不同于一些我看過的其它書，這本書給我的感覺怎麼說，有一種親切感和自然感。他不會把所謂的知識點一條一條的直接給你列出來。而是會通過先抛出問題，引起你的思考，再結合一些事例來進一步推導出結論。給我一種循序漸進的感覺。而且這本書的風格也像是一位前輩在引領後輩前行一般。然而人總是會以懷疑的目光來看待事物，即使這本書給我的觀感不錯。但這本書的主觀性比起别的書要強，總有一些觀點會引起人的争論。這也是無可避免的。
第一章：概論
問題：什麼是bug?
原文中說”簡單的說，軟體的行為和使用者的期望值不一樣，就叫bug”.可如果是因為軟體運作環境或是一些其他與軟體本身無關的原因造成的使用者期望值不同是否也可以稱為Bug？我覺得不能，而且就使用者的期望值本身來說，使用者的期望值還會受到軟體的運作和響應速度的影響。在我看來，Bug應該是指在軟體運作過程中，由于軟體本身原因所造成的軟體無法正常使用或使用時與預期效果不一緻。關于bug原文還曾讨論過bug和feature，也就是說面對與不同的使用者，一些功能也許是部分使用者眼中的bug。那麼對于這些使用者來說這些功能也許是對于他們使用軟體造成困擾和不便。那麼那些對與軟體使用造成某種不利影響但軟體依舊能夠正常運作的功能究竟算不算bug呢？這個問題我一時之間還無法回答。也許應該分情況來推論，還是綜合所有因素一起推論。或許仁者見仁吧。關于bug的消除，一個軟體，或者說一個優秀的軟體。不應該着眼于它的bug的數量，而是應當着眼于它處理bug的能力以及它的持續運作能力。是以關于bug的消除，我們不應該着眼于完全消除bug，因為随着軟硬體的更新，bug應該是無法做到完全消除的。我們應當着眼于如何将bug的影響消除到最低，也就是盡力保證軟體的持續可運作性。
第二章：個人技術和流程
問題：什麼是單元測試？單元測試的意義？
說實話，閱讀過第二章之後，其實是沒有看懂的。關于單元測試就隻有一個很不明了的印象。原文中說單元測試能讓自己負責的子產品功能定義盡量明确，子產品内部的改變不會影響其他子產品，而且子產品的品質能得到穩定的，量化的保證。也就是說單元測試是保證軟體的各部分子產品之間穩定，協調。進一步說，也就是為了軟體的正常運作所做的測試。我不知道我的想法是否是對的。我覺得單元測試就是一個檢測器一般的存在，通過測試來發現子產品中的問題，之後再解決問題。（因為沒有做過單元測試，能說的就真心不多）
第十六章：IT行業的創新
關于創新，真的是老生常談的問題了。現在各行各業都在提倡創新，上至國家，下到個體都覺得創新對于自己本身的發展是有好處的。但全民創新就當真隻有好處？我覺得并不是這樣。書中向我們介紹了很多有關創新的迷思，解讀了很多創新的誤區。我們其實可以仔細思考一下，我們為何創新？無非是為了更大的利益和更快的效率。然而創新的路上，總是失敗了很多次。也就是說創新的風險問題是我們無法回避的。暴雪在做風暴英雄的時候，就告訴玩家會給玩家一個不一樣的moba遊戲，風暴的卻做出了很多創新。但這些創新玩家卻并不買賬。“風暴要火”不僅僅是玩家的一句調侃，也是暴雪作為遊戲大廠創新失敗的無奈寫照。書中引用了憤怒的小鳥的制作工作室的例子來說明曆經反複失敗過後成功的創新。從兩個例子中可以看出，創新是一件高風險，高回報的事。是以，所謂創新絕大多數情況下都不是件容易的事。我們渴求成功，卻也要考慮路上的荊棘。
軟體行業是一個需要持續創新的行業，我也無比期望着軟體行業的未來。