《构建之法》一，二，十六章读后感

《构建之法》一，二，十六章读后感

  初读《构建之法》之时，感觉此书还是值得细细研读的。书中的很多知识与范例，其实都和生活和未来工作有着很近的距离。其中的很多思想和实践值得深思。对于软件工程这门牵涉极广的学科，内容固然重要但如果过度偏向理论或是缺乏实践经验等问题出现，就会导致课程乏味的结果。此书侧重于“做中学“的理论思想，将理论与实际相结合，结构紧密，内容丰富有趣。对于重要的知识理论，以特殊笔体和加粗的方式引起读者重视，很容易在理解中加深记忆，帮助学习。

 以下是对一，二，十六的理解与困惑

第一章

   作为《构建之法》全书的概论部分，首先就从软件=程序+软件工程开始引题，在疑问中以例子在分析一系列的软件开发活动，拓展出软件企业软件+商业模式这个推论；之后点明软件工程的特殊性，即由其本质得出的软件特性；进而剖析了软件工程与计算机科学这两个经常被混淆的专业之间的关系，说明两者之间的交汇与不同侧重；最后在软件工程知识领域和“足够好”软件进行介绍分析，在描述软件学科知识领域的同时指出关于“好软件”的一些标准。章节之中包含的许多问题都很新颖，有着独到和新的认识。

对此章节，我有以下疑惑：

1，“一个好的软件，即使功能与同类软件区别不大，但会让人感到非常好用.......很多非常成功的软件就赢在这个方面” 这种以用户体验为评判依据的方式会不会有失公允？如果侧重于追求用户体验，会不会出现用户体验很好，软件质量却并不是很好的状况。那么究竟该如何权衡在这两者之间的关系呢？根据最近许多网站的调整来看，愈来愈关注用户体验已然成为了热点问题，但其中给出的解决方法仅仅是内容上做的调整与更新，这不失为是一种解决眼下的方法，但随着现如今的发展速度，并不能解决根本问题。因此我认为应该分一部分精力在提高软件质量上，既然是软件质量的基础，进步与更新是必不可少的。因此在如何权衡软件质量和用户体验方面，应该用一个合理的标尺存在吗？

2，由于软件特殊性的限制导致的软件开发流程提速过程缓慢问题，究竟有没有更合理的方法适度加快，毕竟硬件的高速发展会不会导致软件更新速度赶不上，进而导致发展方面的延缓？软件开发流程的目的是为了提高软件开发，运营，维护的效率，并提高软件的质量，客户满意度，可靠性和软件的可维护性。在思想和工具上的更新上实现效率的提高。除此之位，有没有其他方法也能实现软件开发流程的提速呢？

3，对于“足够好”软件这个问题中，bug的确是很重要的要素。“什么是bug呢？软件的行为为和客户的期望值不一样。”如果对于一个拥有许多代码的大型项目中出现bug，那么寻找bug将成为很令人头疼的事件，怎样才能快速细致的找出问题所在呢？查询资料显示：在软件测试中，快不快并不是一个很重要的指标，关键对软件项目测试覆盖程度，bug的发现率和遗漏率。要提高软件质量，被遗漏的bug要少。另外，要加强对系统项目的了解，对开发实现人员情况的了解，了解这些，可以清楚项目的重点难点在哪里，bug往往就是在这些重点难点模块功能上。那有没有更好的寻找方式，能尽量将程序员从改bug中解脱出来，同时降低软件测试方面的难度？

第二章

  此章一开始就先引出单元测试，回归测试和效能分析工具的这三个点。之后在描述了个人开发流程的相关知识和特点。关于单元测试这方面百度的解释是：
“单元测试，是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误。“书中对于好的单元测试标准是准确，快速地保证基本模块的正确性。每一次修改程序就要进行测试，在效能问题上会不会导致效率很低的问题？根据书上内容，有些情况下效能问题可以通过针对代码效率写一个单元测试，那么对于不能以此种方式提高效率的代码，应该怎么解决效能问题？ “100%的代码覆盖率并不等同于100%的正确性！“那对于”应该写但是没有写的代码“有什么好的办法尽量提高覆盖率？

是不是要将没有写出的代码写出来以求增加代码覆盖率，但这样就无形中增加了程序员的工作量，增加的代码也要进行一系列流程与测试。

相关链接：http://baike.sogou.com/v252871.htm?fromTitle=%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95

第十六章

  关于IT行业的创新，这是必不可少的一个部分。但创新也会带来一系列新的困境。本章先由几个创新的迷思点出一些感悟思考，之后在对创新时机，创新招数等方面进行延伸。

在迷思之七，成功团队更能创新这一节来看，成功公司虽然以创新为企业基因，但在拥有成熟市场，成熟技术，稳定客户时，并不想引入太多变数，只要保证这些客户继续使用产品，并继续升级，以“维持性技术“生存。对于对市场尚不可知的颠覆性技术，反倒是没有包袱的小公司进行创新。

”这一纠结的两难表现为：如果公司不断满足已有用户的需求，则产品在趋于饱和的市场缓慢发展，在产品的生命周期结束后，不免会被新的颠覆性创新淘汰；如果公司主动寻找颠覆性创新，则遭到公司内部范围，价值观和文化的排斥。“作为一个成功公司，怎样打破这个纠结的境地，实现公司稳固发展呢？该如何权衡这两方面。

软件创新方面链接：http://blog.sina.com.cn/s/blog_62eaed0301010jx1.html