這本書可以說是我進入大學以來讀過的最容易理解的一本有關於軟件工程的書，語言平易近人容易理解，讓我對軟件工程在原有基礎上有了翻新的認識，讓我重識認識了軟件工程“知行合一”的思想，加深了我對軟件工程行業整體的理解。閱讀的同時，我也產生了一些疑惑，以下是我在學習過第一、二、十六章後提出的一些問題和我的思考！

　第一章：概論

　　問題：在軟件工程發展的短短幾十年中，人們整理了許多原則和規律，有些是比喻，例如“大教堂和集市”，描述了兩種大規模團隊構建產品的方法，這種比喻讓讀者有各種領悟，但大家的領悟都是一樣的，而且在現實開發中，很多團隊在不同階段，以不同程度柔和了不同的方法

　　我的疑惑：“大教堂和集市”兩種方法具體指的是什麽？這兩種的區別在那裏？

　　查詢資料：資料一：http://www.ruanyifeng.com/blog/2008/02/notes_on_the_cathedral_and_the_bazaar.html；如資料中所說集市的特點是開放式建設、成本低、周期短、品質平庸；大教堂的特點是封閉式建設、成本高、周期長、品質優異。這顯然代表了兩種不用的開發方法，在我腦海中第一點想到的是IOS和Android的區別，不知是否準確。

　　　　　　　資料二：http://blog.csdn.net/junior1991/article/details/44100293； 這篇文章解釋了教堂與集市的區別，簡單來說即開源與閉源，隨後還談到了集市模式成功的原因。

　　我之前的實踐：在之前的實踐項目中，我並未遇到過類似的問題，簡單的項目也不會有文中所提到的構建方法的選擇。

　　我仍有的疑問：①、資料二博客中提到 “Windows僅僅只是一個商業系統，完全沒有Linux的精髓，Linux的命令行模式才是符合程序員的正確用法” 為何會有這樣的說法，可視化給操作者帶來了便利，為何要舍近求遠說命令行才是更正確的用法，而且據我所知，Linux也是有可視化模式的。

　第二章：個人技術和流程

　　問題①：在本章所講的個人技術中，重點講到了單元測試和效能分析工具，但對於其他技術並未提及，在我的理解中，單元測試和效能分析工具是代碼編寫後所要進行的步驟，為何書中在個人技術中只介紹了這兩種技術？是因為這兩種技術在所有個人技術中更加重要嗎？（對於這個問題我並沒有在找到相關的資料，麻煩老師能對我進行解答）

　　問題②：原文“我們可以看到，工程師在需求分析和測試這兩方面明顯地要花更多的時間（多60%以上），但在具體編碼中，工程師比學生要少花1/3的時間”

　　我的疑惑：為什麽會出現這樣的差別？

　　資料查詢：http://blog.csdn.net/Jerome_s/article/details/43925225，這篇博客解釋了為什麽程序員應該少寫代碼，“我們的代碼只是一個副產品，是在軟件開發過程中產生的，而對此，我們難以避免，唯有選擇接受。不過，我們可以做的是，多多思考，好好重構，及時刪掉過時的代碼，代之精簡的新代碼”

　　我的實踐：在我所參與過的項目中，還未註意到這樣的問題，作為剛剛進入軟件行業一年的我，應當多寫寫代碼，積累代碼量，厚積薄發，這與程序員要少寫代碼並不矛盾。

　第十六章：IT行業的創新

　　原文中有一段這樣的話：提出一個創新的想法時，我們應該考慮這麽幾點：①對利益相關人要講清楚“你能從中得到什麽”。②創新的想法和目前流行的做法相比，有什麽相對優勢，能讓別人清楚地看到這個區別，並能夠嘗試。③創新和目前大眾習慣、已有系統是否兼容。④避免過度描述復雜的技術。

　　問題：的確，原文中所提到的Dvorak鍵盤布局就是因為和大眾習慣不符而被淘汰的，但如果按照文中提到的思路，那豈非所有的創新（或者說有顛覆性的創新）都有悖於上述的原則？

　　我的思考：創新固然是好的，好的創新能讓生活變得更加方便，更加健康，但創新會損害行業相關這的利益，會被原有的受益者排擠和損害，這是不可避免的，既然這樣的損害是不可避免的，那好的創新想要存活下來就更要重視目前的大眾習慣，是否容易被大眾所接受，Dvorak鍵盤布局失敗的原因便是在大眾的習慣已經固定，不可能讓已經形成習慣的人去重新學習打字，至少這件事發生在我身上的時候，我是不會接受的。

綜上，是我在學習了鄒老師的《構建之法》的一、二、十六章後的一些看法和一些未能自己解決的疑問，希望能得到老師的指點～

構建之法1、2、16章閱讀感想