对于一本关于软件工程的教材我想大部分的读者第一印象就是枯燥、乏味，通篇多是高深难懂的代码让读者看的昏昏欲睡。但《构建之法》却给我们别样的感觉，作者把软件开发的方法讲的清晰有趣实用，并有相关的人物扮演不同的角色贯穿全书，让我们有一种看小说的感觉，看了开头就有一种想继续往下看的冲动。但仅仅是有趣并不是一本好书的评判标准，此书不仅拥有大量的趣味性，更不缺乏强大的实用性。作为一个菜鸟学员，对于将来的工作一定是充满了未知的，而此书却通过菜鸟程序员个人开发到一个团队的组成进行了全过程的讲解，让我们了解到了一个团队的出现是需要经历各种磨合和考验的。
对于软件相关专业的我们来说，学习了很多的专业课程，像算法，数据结构，编译原理，软件工程等。很多学生都会有这样的疑问：我学了这么多的课程有什么用呢？在工作中有多少会真正被应用到呢？也就是说，大家都觉得理论和实践之间有着不可逾越的鸿沟。该书的内容主要以设置情景，采用一问一答的形式为软件开发测试等各领域的一些常见问题用最简单的文字回答，对于一些比较难懂的概念性较强的专业名词也会以故事或情景及我们生活中的小例子来解释，让我们可以在轻松简单的文字或例子中明白其深意.
通过对《构建之法》的学习，让我了解到了一个软件的生命周期从需求分析开始直至软件的淘汰的过程中最重要的一环是——软件测试，对于软件测试按测试设计分类可分成黑盒测试和白盒测试，但在实际工作中，我们不应画地为牢，严格只用某一种测试方法来对软件进行测试。而按测试的目的来分，软件测试又可以分成功能测试、非功能测试。而测试方法又是各种各样：单元测试和代码覆盖率测试、构建验证测试、验收测试、探索式测试、回归测试、场景/集成/系统测试、伙伴测试、效能测试、压力测试、内部/外部测试、易用测试、”小强“大扫荡等等方法。而在实战中的测试是在项目的稳定阶段执行的，因此这一阶段的核心任务是在满足最低接受条件的前提下，提高各个部分的质量。而正如开发人员有功能设计说明书，测试人员也要有测试设计说明书，告诉测试人员要如何设计测试。总而言之，软件测试是保证软件质量的优先条件，只有在排除了大量的bug之后的软件才有来评判该软件的”好“、”快“、”便宜“这一系列的软件质量问题，才能有后面的软件创新之类的延续。
总之，我个人认为这是一本浓缩了无数精华的好书，像我们读软件的或者是在从事软件行业的人，都应该人手一册，如果把我们搞软件的人比作是一群行兵打仗的人，那《构建之法》就是我们的《孙子兵法》！
问题：
1.对于一个软件，要测试到什么程度才叫测试好了？
2.正如不同层次的人会买不同价格的车，那么对于软件是不是也应该按给出开发价格的高低来对软件进行不同程度的开发测试呢？
3.合格的软件工程师，有什么具体的标准吗？
4.敏捷流程中，每一步做什么都考虑的很详细，但是真正的工作有些问题做不到的，该怎么办？
5.代码复审真的有那么重要吗？