关于阅读《构建之法》一、二、十六章的思考

第一章、概率

 

     看完了第一章以后，了解到了我们软件工程与计算机科学的区别，就像我们软件工程更加注重于工程二字，而计算机科学更加注重于科学，还了解到了我们软件工程专业所涉及到的领域，但是还是有一点疑问。

     问题一：Bug到底是不是一个真正的bug，该怎么去平衡bug？

     我以前了解到的bug，就是字面意思——缺陷，瑕疵，但当我看到书上1.2.4上引用的经典小说的例子包括后面的解读，我就陷入了思考，bug在这里面是否还是一个真正意义上的bug，书上说，我们软件行业有一句著名的笑话：这不是缺陷，这是一个功能。 

    然后我就去上网搜索了一下bug的含义，这是百度上所给出的bug含义，他的意思就是未被发现的缺陷和问题，书中说是否是bug是取决于用户，开发者的不同角度，我也认同这样的观点，但这样到底什么样的才能叫bug，我认为bug是修补不完的，这个问题解决了，还会有另外的问题，一直会有人不满意你的这个程序，而且还要考虑时间，成本等多种约束条件，那我们应该怎样去平衡呢？

 

第二章、个人技术和流程

 

    看了第二章之后，不明白的地方还是有很多，尤其是有一些术语不懂，刚开始看第一遍的时候，感觉什么都不太明白，后来第二遍，第三遍就好一点，也能逐渐理解了

    问题二：什么叫做单元测试和回归测试？

    书中一上来讲的就是单元测试，对于我这种没有太多的项目经验的人，是不太理解的，而且书中也没有一个明确的说明，后来在看书的过程中，我慢慢理解了单元测试，我猜想它可能是保证一个模块的质量，使模块的功能尽量明确，然后再继续读书的过程中又遇到了回归测试，书上说回归测试是基于单元测试的基础，我也不是特别明白，在读完第二章第一遍之后，我百度了一下单元测试和回归测试，以下是搜索结果

 

    虽然说大致明白了，但是还是有点不太理解，这些测试具体应该怎么用，在什么地方用，这些对我还是个问题。

   问题三：回归测试应该怎样实现自动化？

    书上说，回归测试最好要自动化，这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。我不太理解回归测试应该怎样实现自动化，然后我去搜索了一下，没有找到答案，所以还是有很大的困惑。

第十六章、IT行业的创新

 

    读过第十六章之后我对创新也有了自己的思考，我之前认为创新就是在这个领域非常有成就的人深入研究，发现了或发明了一个颠覆性的东西，但当我看到书中16.1.5迷思之五时，才突然明白原来创新的人都是在他们拿手领域之外发现的，仔细想想好像确实是这样。但同样对这章我还是有一点疑问。

    问题四：成功的团队真的不可能再有颠覆性的创新了么？

    现在时代更新换代很快，我们都不知道那种东西什么时候就会被淘汰掉，所以我认为一个成功的团队应该保持自己的创新性，跟上时代脚步，如果一个成功的团队，只在维持自己的技术，那么他很有可能会被逐渐淘汰，因为就像书上说的一样，总有一些小公司反而能把颠覆性的创新带到市场，挑战成熟企业的霸主地位，所以我觉得一个成熟的企业应该保持自己的创新积极性。

    以上就是我读了《构建之法》一、二、十六章的一些感悟和疑惑。