这学期，我开始学习《构建之法》这本书。之前的我，除了课本很少去读一些专业课本，总觉得那些专业书又厚又晦涩难懂。然而《构建之法》这本书却让我有不一样的感觉。首先这本书没有特别厚，字也没有很小，让我从心里开始接受它。等我真正去读，发现它并没有那么晦涩难懂，相反还挺有趣。
这几天我主要读了第一章、第二章和第十六章，刚开始读了一遍，跟着作者的思路走，并没有什么自己的想法。于是，我又开始读，试着提出自己的想法，以下是关于这三章，我的一些想法，可能不是很准确，希望与老师、同学们互相学习指正。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
第一章 概论：
1.“软件=程序+软件工程”
问题：程序与软件的区别是什么？
回答：以前我总是分不清何为程序,何为软件，一直以为比较完善的程序就是一个软件。于是，我上网查了资料，更加明确两者的区别：
程序（program）是为实现特定目标或解决特定问题而用计算机语言编写的命令序列的集合。为进行某活动或活动所规定的途径。
一个程序应该包括以下两方面的内容： （1）对数据的描述。即数据结构。 （2）对操作的描述。即操作步骤，也就是算法。
这也就是我们常说的：程序=算法+数据结构
软件：软件是一系列按照特定顺序组织的计算机数据和指令的集合。(与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。)
另外，该书给出软件工程的定义是：把系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护上的过程，也就是说将工程化应用于软件。但根据我对“软件=程序+软件工程” 这个等式的理解，软件工程是不是也可以理解为将工程化应用于程序？
2.“没有银弹“理论
不管是上课还是看书 都对“没有银弹”这句话印象比较深刻，文中说“软件的这些非本质、临时的特性并不能解决软件工程的本质问题。例如，有人发明了一种新的程序设计语言等并不能改变软件工程的根 本难度，也就是著名的“没有银弹“论断所阐述的问题”。看完这段话，我想我对‘‘没有银弹”中 “银弹”“所指的改变的程度究竟是什么产生了好奇。于是，我上网搜了一下：《没有银弹》是Fred Brooks在1987年所 发表的一篇关于软件工程的经典论文。该论述中强调真正的银弹并不存在，而所谓的没有银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。
3.“如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？文中给出的这个需求是飞机的安全功能，面对这个需求，我们当然选4.做了，而且不厌其烦的告诉用户如何使用。”
问题：在企业去做一个软件时，如果一个需求用户使用它的概率是百分之一，我们需不需要去做，如果使用率是五十分之一，十分之一呢？（当然这个需求不是涉及安全方面的）
回答：我的个人想法是要看企业对这个软件所投入的精力、时间、金钱以及这部分需求未来的发展空间。如果，公司有足够的精力以及通过对市场的调查发现该需求将来会有很大的发展空间，我们可以做。但如果这部门需求可能在未来不会有很好的发展或者企业没有足够的精力去做，那我们可以集中精力将软件的主要功能完成，其他次要的以后再说。（根据实际情况具体分析）
第二章 个人技术与流程
1. 2.1.1用VSTS写单元测试
在该部分，举的例子是用c#写的，因为之前并没有了解这部分的内容，所以，看起书来不是很懂。希望老师在上课时能用同学们学过的Java或者c语言举例给同学们讲解一下。
2. “最好在设计的时候就写好单元测试，这样单元测试就能体现API的语义如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。”
问题：(1)在设计的时候就写好单元测试？(2)单元测试应该写多细？
回答(1)：
我查了一下资料，关于什么时候写单元测试，网上的说法主要有以下三个时间段：
a.一是在具体实现代码之前，这是测试驱动开发（TDD）所提倡的；
b.二是与具体实现代码同步进行。先写少量功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）；
c.三是编写完功能代码再写单元测试，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差。
关于什么时候写单元测试最好，我认为在第（1）个时间段跟第（2）个时间段都可以，不知道同学们与老师的想法是什么？
回答(2):
根据我看了几篇博客，知道了单元测试不是越多越好，而是越有效越好！进一步解读就是哪些代码需要有单元测试覆盖： 逻辑复杂的、容易出错的、不易理解的（即使是自己过段时间也会遗忘的，看不懂自己的代码，单元测试代码有助于理解代码的功能和需求 ）、公共代码（比如自定义的所有http请求都会经过的拦截器；工具类等）及核心业务代码（一个产品里最核心 最有业务价值的代码应该要有较高的单元测试覆盖率）。
第十六章 IT行业的创新：
1.“迷思之五：要成为领域的专家，才能创新。”
“但是据统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。”
个人想法：
作为一个学软件的大二学生，我在软件这个领域，并不是一个专家，甚至可以说只是一个初学者。但我不能创新吗？相反，我们现在有很多创新创业的比赛，鼓励大学生创新创业。正如我们今年 打算做的国创项目，我们只是有个想法，并不知道我们能不能做出来，但我们会为了我们这个创新的想法，去学习让这个想法成为现实所需要的技术。因此，站在我的角度来看，创新没有前提，只要有好的想法，我们就可以为了实现这个想法，成为这个领域的专家。
2.“迷思之八 ：创新者就是冒险家”
“其实根据研究，创新人士的关键特点不是喜欢冒险，也不是躲避风险，而是从错误中恢复并继续努力，就像文言文说的’屡败屡战‘。”
问题：创新者不需要冒险精神？
回答：我认为，冒险精神对于创新者而言是必要的。只有具有冒险精神，创新者才能敢于尝试，敢于突破，勇于实践，从不畏惧失败，从失败中不断汲取经验，才能够做到文中所说的”屡败屡战“。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以上就是我关于这三章的一些想法，希望与大家多交流，共同进步。努力努力再努力！