第一章
概述：本章主要讲了软工和计算机科学的关系，区别，软工的性质，定义，组成。这一章印象最深的是虫与肉芽的故事。还有作者加引号的足够好。
问题一：BUG的真正定义是什么，它有分类吗？
通过阅读第一章，我体会到BUG这一词汇的含义或许很丰富。它可能是实指在构建过程中一些编码的漏洞，我认为这是一种可以调节和改正的实质性的编码语法或逻辑性上的错误。它也可能是一些不能称之为错误的“错误”，或许更改说是一种“失误”。或许是在构建产品模型之初对市场，对用户需求分析的失误，或许是因为产品经理跟客户之间沟通不畅而导致的失误，又或许等等等等。我查了一些资料，怎么说，定义很模糊，分类更没有。希望老师很同学们可以帮我解答一下。
问题二：“足够好”的软件
我同意作者的观点。完美的软件有吗？应该没有吧。“足够好”的软件，我想一定有。它应该是某一领域下综合性能最好，最有价值的一款软件。可以较好的满足用户的需求，就有良好的可靠性和可维护性。人的需求无止境，BUG永远调不完，时间不等人，成本有合算，足够好就可以。
第二章
概述：本章主要讲了测试（单元测试，回归测试），效率改进和PSP。这一章对我冲击最大的是测试。这应该算我第一次真实地了解“测试”。在以前的很多时候，我了解的测试只是软件生命周期中软件构建之后，软件维护之前的一 个字符。它或许也就是调一调程序，改一改BUG，仅此而已。
问题一：软件项目交付之后，BUG多是测试的错吗？
读了第二章，我明白了单元测试是从构建之初就开始进行的，无论是自己写写程序还是一个团队合作一个项目都要贯穿始终的。单元测试的目的是让不同的人在不同的时间，仍然可以读懂这一单元可以做的事和不可以完成的事，并且，它可以帮助程序员记录这个模块的历史和设计变更的理由。而回归测试是在新的构建出现问题，这个模块从正常工作退化到不能工作之后，进行的大规模，全面的测试。那么问题来了，当软件项目交付之后呢，BUG多是测试的错吗？
我逛了逛一些论坛和博客，发现软件项目交付之后，BUG产生的原因有很多。在项目开发方面，开发人员开发完后并没有进行单元，测试在测试回归阶段会因为一些隐秘的东西，测不全。或者是后期更改需求了，开发人员加进去了，但是测试并不知道。我觉得这些都是可以通过单元测试来解决的。这时候，单元测试就好比语句后的注释，告诉我们它可以干什么不可以干什么，又好像是一个日志，记录程序做的改动。但是还有一些情况，测试是不背锅的。比如：产品原型没有搞清楚清楚，有歧义。产品经理跟客户之间没有沟通好，有歧义，没有真实的了解客户的需求，而导致后期交付时，被当作了所谓的BUG。这时，就应该在建立产品原型之后马上让测试人员介入，和产品经理一起再次梳理原型，可以更好的减少不必要的麻烦。
第十六章
概述：这一章主要讲的是创新。很俗的话题，但是作者的某些观点或解答了我的疑惑或让我有思考。
问题一：灵光一现后是创新？
说实话，我以前真的是这样觉得的。但作者提到“科学巨人在顿悟之前已经在相关的学科打下了深厚的基础，同时他们也为这些问题进行了长时间的思考”，是的，你永远看不到巨人的背后是什么，因为你已经被他们的灵光一现迷了眼。同时他们作为一个单独人工作，而非IT领域的团体。一张画需要很多块的拼图，这是持续创新的结果。也就是说IT的创新是积累的。 IT的创新还是实践的。没有实践的创新好比是汽车的图纸，，开不起来，算什么车呢？ IT的创新是圆形的。在实践的过程中，困难是一定的，那么如何解决困难，用什么方法，可以借鉴前人，也可以另辟蹊径，这又会是一次创新。所以创新是圆形的。
这是我在本次《构建之法》第一二十六章的阅读过程中的一些问题和所思所想，希望老师批评指正不足之处，谢谢老师。