一、前言
不同于以往的解决问题，这次是需要阅读，自己思考来提出问题。经过阅读书上的部分内容，再结合一年半以来的大学经历，我也清楚地认识到了，它并不是我想象中的那么单纯的以代码去实现一切。正如专业的名称，完成软件开发就应该像是完成一项“工程”，需要分析设计构建维护等。书中的介绍使我对软件工程又有新的认识，但是在经过阅读后所获得的又一轮新的认知中，又有些许不太清楚，或许也有些不敢苟同的地方。关于个人主观提出问题，如下。
二、关于问题
第1章 概论：
“软件工程是把系统的、有序的、可量化的方法应用到软件开发、运营和维护上的过程。”
“如果一架民用飞机上有一个功能，用户使用它的概率是百万分之一，你还要做这个功能么？”
软件工程是什么？不是来自于定义，而是从事软件开发的经验抛开概念的自我理解的通俗解释。
个人觉得就好比汽车上的安全带，我们坐上车就会使用，只是它发挥作用可能是很小的概率。飞机的安全功能用户几乎都是在使用的，只是它发挥其作用只有可能是百万分之一，而且安全功能在我的认知中无论是哪里都是明令必须的，因此，在例子中感觉稍有些不太合适。
第2章 个人技术和流程：
“单元测试”“效能分析工具”
这一章主要是对这两个陌生的词汇有疑问，结合书中知识和百度百科后得到解答。通俗点理解单元测试就是指开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。单元测试通过了就不意味着程序就没有不足？我觉得单凭一段代码的测试就算多次应该也无法排除全部bug吧，毕竟可能出现的“巧合”也还是有的。
第16章 IT行业的创新：
“迷思之七：成功的团队更能创新”
书中似乎否定了在我以往的认知中一个成功的团队应该是更加有创新的活力的观点。抑制创新的想法是必遭淘汰的，无论何时都是不为时代的变更，社会的进步所容的。一个成功的团队也应当是更能创新的，因为一个在创新方面落后压抑着创新思想的团队纵使现在是成功的，那也可能只是一时的成功，将来也必遭淘汰。就比如诺基亚衰落很大一部分原因就是因为设计理念的应循守旧，没有革命式的创新，而渐渐被其他公司给比下去。更能创新的能力不也正是一个成功的团队所必须的吗？否则，迟早会被其他团队所比下去，赢在一时应该也不可谓之成功吧。另外，企业是以利益为基准的，这个在书中也有提到，但是是用来否定这个观点的，个人认为如果从创新带来的收益来讲，如果能够推广这份创新，应该更强于缺少创新的情况吧。当然这些也许只是对各种特定词汇的理解不同和对于实际上目前形势的不理解才导致的疑问，只是一些个人的看法和不成熟的观点。