一，二，十六

         很长世间以来我对于专业书的印象一直都是觉得就是一堆知识知识整齐的排列在书上，很方便也有些许无趣。《构建之法》却让我对于专业书的整体想法有了不同的看法。不同于一些我看过的其它书，这本书给我的感觉怎么说，有一种亲切感和自然感。他不会把所谓的知识点一条一条的直接给你列出来。而是会通过先抛出问题，引起你的思考，再结合一些事例来进一步推导出结论。给我一种循序渐进的感觉。而且这本书的风格也像是一位前辈在引领后辈前行一般。然而人总是会以怀疑的目光来看待事物，即使这本书给我的观感不错。但这本书的主观性比起别的书要强，总有一些观点会引起人的争论。这也是无可避免的。

 第一章：概论

 问题：什么是bug?

     原文中说”简单的说，软件的行为和用户的期望值不一样，就叫bug”.可如果是因为软件运行环境或是一些其他与软件本身无关的原因造成的用户期望值不同是否也可以称为Bug？我觉得不能，而且就用户的期望值本身来说，用户的期望值还会受到软件的运行和响应速度的影响。在我看来，Bug应该是指在软件运行过程中，由于软件本身原因所造成的软件无法正常使用或使用时与预期效果不一致。关于bug原文还曾讨论过bug和feature，也就是说面对与不同的用户，一些功能也许是部分用户眼中的bug。那么对于这些用户来说这些功能也许是对于他们使用软件造成困扰和不便。那么那些对与软件使用造成某种不利影响但软件依旧能够正常运行的功能究竟算不算bug呢？这个问题我一时之间还无法回答。也许应该分情况来推论，还是综合所有因素一起推论。或许仁者见仁吧。关于bug的消除，一个软件，或者说一个优秀的软件。不应该着眼于它的bug的数量，而是应当着眼于它处理bug的能力以及它的持续运行能力。所以关于bug的消除，我们不应该着眼于完全消除bug，因为随着软硬件的更新，bug应该是无法做到完全消除的。我们应当着眼于如何将bug的影响消除到最低，也就是尽力保证软件的持续可运行性。

      第二章：个人技术和流程

      问题：什么是单元测试？单元测试的意义？

      说实话，阅读过第二章之后，其实是没有看懂的。关于单元测试就只有一个很不明了的印象。原文中说单元测试能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的，量化的保证。也就是说单元测试是保证软件的各部分模块之间稳定，协调。进一步说，也就是为了软件的正常运行所做的测试。我不知道我的想法是否是对的。我觉得单元测试就是一个检测器一般的存在，通过测试来发现模块中的问题，之后再解决问题。（因为没有做过单元测试，能说的就真心不多）

      第十六章：IT行业的创新

      关于创新，真的是老生常谈的问题了。现在各行各业都在提倡创新，上至国家，下到个体都觉得创新对于自己本身的发展是有好处的。但全民创新就当真只有好处？我觉得并不是这样。书中向我们介绍了很多有关创新的迷思，解读了很多创新的误区。我们其实可以仔细思考一下，我们为何创新？无非是为了更大的利益和更快的效率。然而创新的路上，总是失败了很多次。也就是说创新的风险问题是我们无法回避的。暴雪在做风暴英雄的时候，就告诉玩家会给玩家一个不一样的moba游戏，风暴的却做出了很多创新。但这些创新玩家却并不买账。“风暴要火”不仅仅是玩家的一句调侃，也是暴雪作为游戏大厂创新失败的无奈写照。书中引用了愤怒的小鸟的制作工作室的例子来说明历经反复失败过后成功的创新。从两个例子中可以看出，创新是一件高风险，高回报的事。所以，所谓创新绝大多数情况下都不是件容易的事。我们渴求成功，却也要考虑路上的荆棘。

     软件行业是一个需要持续创新的行业，我也无比期望着软件行业的未来。