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

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

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

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

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

第一章:

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

第二章:

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

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

第十六章:

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

原文地址:https://www.cnblogs.com/anheqiao/p/8563521.html