看完构建之法1、2、16章的几个问题

如何提出有价值的问题呢？字数多的问题就一定是好问题吗？生成一个好问题需要精读，什么叫精读呢？当你对某句话感到困惑或者质疑的时候，去对每个词翻阅资料再联系上下文去理解。

比如，我在初读本书的一个定义的时候，它说，源程序就是构建在数据结构上的算法。我想，数据结构不就是数据集合的构造类型麽，算法是对数据的输入进行逻辑运算产生结果，说源程序就是构建在数据结构上的算法是否不严谨。我想质疑作者，所以需要更加详细科学的解释去反驳作者的观点，于是我查了很多资料。

数据结构是计算机存储、组织数据的方式。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。通常情况下，精心选择的数据结构可以带来更高的运行或者存储效率。数据结构往往同高效的检索算法和索引技术有关。算法（Algorithm）是指解题方案的准确而完整的描述，是一系列解决问题的清晰指令，算法代表着用系统的方法描述解决问题的策略机制。也就是说，能够对一定规范的输入，在有限时间内获得所要求的输出。这才发现，本书中，构建一词用的非常好，基本不需要额外的解释去定义源程序这个概念。源程序，是一行行代码，代码中包含了众多用于解决问题的算法，算法是构建在相互之间存在一种或多种特定关系的数据元素的集合，也就是构建在数据结构上。我开始真正理解源程序是什么意思。也对算法和数据结构的定义清晰很多。

如果，我没有精读，就不会对定义产生质疑，没有质疑，就没有反驳作者而产生的动力去查阅资料，不查阅资料，就不知道自己知识上的漏洞。这个道理我要时刻记住，读要精读，要勇于质疑，也要敢于反思。

第一章：

　　一：1.21 软件的特殊性里，Fred Brooks Jr在No Silver Bullet里总结的第二点——不可见性，我不太明白它为什么是有价值的难题。书中说，工程师几乎无法完整重现程序到底出了什么问题。确实，着很难做到，但是，做到它有什么意义呢？我们无论是在工作上还是学习上，都可以通过错误提示，或者逻辑判断来分析错误原因，从而修改代码，来让代码运行出自己想要的模样。那么，书中说的不可见性，“工程师不知道自己的源代码如何具体地在用户上的机器上被执行的”着样，对于我们来说，是值得研究的难题吗？我想，着可能对于研究硬件的人来说是一个值得研究的问题吧。

第二章：

　　一：2.1单元测试，从21页开始的这个部分单元我一直不太懂，我明白什么是单元测试，书上或者是百科的定义都非常清楚。但是，我清楚的仅仅是它的定义， 我明白从设计代码开始就要设计如何去测试它，测试代码中的最小单元。那么，值得测试的最小单元是什么？如果对每个类都测试的话，费时费力，我感觉，不需要对所有的类进行测试，选择最值得测试部分才最有价值是吗？或者说，只测试类的接口，这样更方便，也容易排查bug。

　　二：2.2效能分析工具，只有一个很简单的问题，老师会讲如何实践抽样和代码注入吗？我很希望得到老师具体点的实践讲演，因为光看书上的东西，无法掌握这门实用的技能。

第十六章：

　　一：16.3.6 四个象限划分产品。我认为这样的划分是没有问题的，但是我觉得，对于一个团队来说，这么划分有些过于简单了。因为，不是说它是个杀手产品就一定值得团队去花绝大数精力去做。例如，人工智能在某某方面的应用，团队有思路，也有技术，市场调查显示非常有市场，不过做出来需要10年，等到做出来黄花菜都凉了。所以，不能这么简单划分4个象限，而是添加多方面因素糅合进去，建立一个比较适合的模型，才有利于团队实施正确的产品开发策略。