构建之法1、2、16章阅读感想

　　这本书可以说是我进入大学以来读过的最容易理解的一本有关于软件工程的书，语言平易近人容易理解，让我对软件工程在原有基础上有了翻新的认识，让我重识认识了软件工程“知行合一”的思想，加深了我对软件工程行业整体的理解。阅读的同时，我也产生了一些疑惑，以下是我在学习过第一、二、十六章后提出的一些问题和我的思考！

 

　第一章：概论

　　问题：在软件工程发展的短短几十年中，人们整理了许多原则和规律，有些是比喻，例如“大教堂和集市”，描述了两种大规模团队构建产品的方法，这种比喻让读者有各种领悟，但大家的领悟都是一样的，而且在现实开发中，很多团队在不同阶段，以不同程度柔和了不同的方法

　　我的疑惑：“大教堂和集市”两种方法具体指的是什么？这两种的区别在那里？

　　查询资料：资料一：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键盘布局失败的原因便是在大众的习惯已经固定，不可能让已经形成习惯的人去重新学习打字，至少这件事发生在我身上的时候，我是不会接受的。

 

综上，是我在学习了邹老师的《构建之法》的一、二、十六章后的一些看法和一些未能自己解决的疑问，希望能得到老师的指点～