閱讀筆記

我在閱讀書籍的時候，大部分都是瀏覽，也許是跟我看的書籍的內容有關系吧，但是，在瀏覽過《構建之法》這本書後，我精讀了它，以下是我在閱讀完1，2，16章後有的想法和問題，希望和大家一起分享和討論。質疑和不斷探索會幫助大家進步。

第一章 概論

引用

軟件團隊要從需求分析（Requirement Analysis）開始，把合適的需求梳理出來，然後逐步開展後續工作，如設計（軟件架構）、實現（寫數據結構和算法）、測試，到最後發布軟件

問題一：需求易變，可否將需求分割成為細密的任務點？

好的軟件，一定會有很好的用戶體驗，不同的用戶對軟件的功能和界面有不同的需求，而在開發過程中，有時會出現需求變化的情況，有些變化甚至可以將整個項目推倒重來。這樣，我們在對需求的實現過程中，任務點分配或許可以幫助軟件提高其本身的可維護性，對於軟件的後續發展也有些許進益。

引用

什麽是Bug呢？簡單的說，軟件的行為和用戶的期望值不一樣，就叫Bug，是否是Bug，取決於用戶、開發者的不同角度。

問題二：當用戶的期望值和軟件的優化方向起沖突時，應當如何抉擇？

業務方面與用戶方面之間產生了沖突，如果我們將業務層面的需求簡單考慮之後，我們再進行對用戶方面的思考，這個時候，我們所面對的一些用戶需求，有時候很容易和業務目標之間有會沖突，當我們圍繞用戶期望為中心去設計時，業務目標往往不能很好的達成，而實際上，正確的思維方式應該是，以業務目標為基準去推導用戶的行為，當這個行為和用戶目標相違背時，我們應該想辦法把用戶不喜歡做的事轉化為和用戶使用動機相關的事情，引導他完成。

根據我所查閱的資料顯示：

從開發者的角度，解決方案圍繞四個點進行：

1、 尋找業務和目標的關聯

2、 確定相對平衡的方向

3、 提供多個設計方案

4、 最終方案呈現

第二章 個人技術和流程

引用

單元測試必須由最熟悉代碼的人（程序的作者）來寫。代碼的作者最了解代碼的目的、特點和實現的局限性。所以，寫單元測試沒有比作者更適合的人選了

——P25

問題一：單元測試一定要作者自己寫嗎？

查閱了部分資料後，發現了開發人員和測試人員都可以寫單元測試；對於一些測試人員供給不足的小公司，要求開發人員寫單元測試，而對於一些大公司，常常設置有測試部門進行。開發人員對代碼最熟悉，而且開發技能也強，開發自己寫單元測試效率上和覆蓋率上都比較高。而且單元測試有時候需要開發對代碼進行部分重構才方便進行，開發自己做這些重構也比較順手。但是開發人員可能會因為業務代碼的繁重而顧不及單元測試的書寫，如果只是寫單測對軟件的進益幫助不大。測試人員寫測試有比較好的測試思想，可以更好地保證用例的覆蓋。而且通過寫單測測試能更好地了解具體代碼結構、流程，對於後續的業務測試也有利。但是測試人員對代碼沒有開發人員熟悉。

具體怎麽選擇就是個問題。

第十六章 IT行業的創新

引用

迷思之一：靈光一閃現，偉大的創新就緊隨其後

迷思之二：大家都喜歡創新

迷思之三：好的想法會贏

迷思之四：創新者都是一馬當先

迷思之五：要成為領域的專家，才能創新

迷思之六：技術的創新是關鍵

迷思之七：成功的團隊更能創新

迷思之八：創新者都是冒險家

——P340-P354

問題一：IT業創新究竟需要什麽？

對於軟件開發人員來說，創新是非常重要的。在這個需要創新的時代，無論什麽行業都需要創新。但是在如今的時代，進行前無古人的創造難度很大，在某些情況下我們需要在前人的基礎上進行一定的創新。

有時候，創新並不是能被所有人接受的，每個新事物的出現都需要一定的時間才能被人們接受。如果我們有好的想法，就要搞清楚我們能從這個想法中得到什麽，現在自己具備的條件，以及與這個時代是否兼容。否則好的想法也不能付之實踐。

創新者通常都會很成功，但是這些人一般不會是先行者。在IT行業中，系統項目或者其他軟件是經過不斷的創新開發才得以完善。大部分人會覺得自己不是這一領域的專家人才，而不願意去嘗試，但是蒂姆-伯納斯李就實現了，他是物理學家，實現了HTTP協議通信。

創新並不是必須要一個非常優秀的團隊才能完成的事情，如果一個軟件開發團隊有技術，有耐心，有團結心，有嘗試的勇氣，未來有無數種可能性，創新也有無限種來源，他們也可以成功。

《構建之法》問題與思考