构建之法读后感
这次个人阅读选择的书籍为《构建之法：现代软件工程》（邹欣 著）。我们这门课程也参考了很多这本书的结构、内容与方法，读这本书，既是对学过知识的复习和细化，也是对以后课程的预习。
下面总结了几个阅读过程中理解有困难或疑问的point，有的是细节，有的是大的方法。然后在网上查找学习了相关内容，与大家分享。
1. 第4章 两人合作 —— 4.3 代码设计规范 —— 4.3.3 错误处理
此处提到了“断言”的概念，但着墨不多，介绍简略。
那么问题来了，挖掘机……不是，断言是什么？
编写代码时，如果程序员相信在程序中的某个特定点某表达式值（布尔式）为真，可将其标为断言（assert）。
举个栗子：
public class AssertionDemo{
public static void main(String[]args){
int i; int sum=0;
for(i=0;i<10;i++){ sum+=i; }
assert i==10;
assert sum>10&&sum<5*10:"sum is "+sum;
}
}
上述程序中语句assert i==10断言i的值为10，如果i的值不为10将抛出AssertionError异常。语句assert sum>10&&sum<5*10:"sum is "+sum断言sum<5*10，如果为false，将抛出带有消息"sum is "+sum的AssertionError异常。
如果肯定某件事一定要发生，则可以使用断言；如果这件事有别的可能，则应用if……else处理。
由于可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言，而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新起用断言。
P.S. 此问题算个人知识的不足，之前不了解断言的概念。
2. 第5章 团队和流程 —— 5.3 开发流程 —— 5.3.2 瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。它在1970年由温斯顿·罗伊斯（Winston Royce）提出，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
本书中例出了瀑布模型的文档图，但是鄙人并没有看得很懂它的用意。
搜索一些关于瀑布模型的解释后看到了这样一句话：”瀑布模型的本质是‘一次通过’；它是一种文档驱动模型，在可运行产品交付之前，客户只能通过文档来了解最终的产品会是什么样子。“
这才恍然大悟书中那个8种文档被各个过程生产、修改的含义。由于瀑布模型是线性的，在最终产品产生前，如何产生有用的文档指导开发、衔接两个阶段非常重要。
3. 第6章 敏捷流程 —— 6.5 敏捷的故事
这一小节中有一个图表，对比了敏捷（Agile）、计划驱动（Plan-driven）、形式化的开发方法（Formal Method）的适用范围。里面提到的形式化的开发方法，其基本步骤是怎样的呢？为什么它能有极高的可靠性呢？下面是一些关于形式化方法特点的说明，从中可以看出它能力的缘由。
形式化方法建立在严格的数学基础上，其目标是希望能使系统具有较高的可信度和正确性，并能使系统具有良好的结构，使其易维护，关键是能较好地满足用户需求。“形式化方法”一词虽然一直被广泛地应用，但在不同程度上，因理解不同，使其具有了不同的含义。一般说来，形式化方法是指具有坚实数学基础的方法，它是数学上的综合、分析技术的应用，用于开发计算机控制的系统，经常有推理工具的支持，它可提供一个用于模型设计和分析的一个严格而有效的途径。
形式符号系统具有一定的数学性质，所以它们非二义性的基础在于其内在的数学结构。越是复杂的数学概念，越是建立在更原始的概念之上，如：集合、命题逻辑。这就是说，形式符号系统可以具有合适的解释，并在理论上足以确保规范的一致性解释。 形式规范是由一些精确的定义组成的，因为其符号系统的含义是明确定义的。相对地，若将英语作为交流媒体，将很难得到精确的规范。精确规范的直接益处在于：它能减少规范中的二义性和误解释的可能性（危险）。精确是形式化方法或形式符号系统的一个特征，是产生无二义性规范的主要依据。另外，形式规范主要的语用益处在于：可以对形式规范进行较详细的构造性检查，因为对此规范中的具体内容的含义不会有争议，有争议的只是内容的完备性。换句话说，精确有助于确认和交流。 由于适当的形式机制的使用，使得规范的抽象性成为可能。抽象是人们处理复杂性的主要智力工具之一，而且通过忽视不感兴趣的部分，从而有助于清晰性。各种形式符号系统对于精确、抽象地表达概念具有各自不同的能力，但它们均可用于严密地描述概念，更重要的是，它们比自然语言的描述更严密、更精确、更抽象。一般地，形式系统（框架）使得表示一个规范与其相应程序之间的映射成为可能。 形式规范有一个很有价值的特性：可操纵性。这就是说，可以在明确定义的规则的指导下，分析规范或或对形式规范进行变换。利用形式规范的可操纵性可以证明规范的一致性；可以推导出关于此规范的一些重要结果；还可以验证规范的实现过程，至少可以验证源代码相对于其规范的正确性。更一般地说，有可能将不同级别规范间的验证以及规范与程序间的验证问题简化为形式证明问题。这样，形式化方法就可以提供程序对应其规范的非常高的可信度。所以，可操纵性也有助于确认，并且由这种特性可以得到进一步的抽象（推导出的性质），同样，也有助于使得规范更清晰。
4. 第6章 敏捷流程 —— 6.5 敏捷的故事
这一小节提到了几种比较出名的敏捷开发方法论，如FDD、Scrum、XP、TDD。前三者在书中都有专门的介绍，但TDD，久闻其大名，到底是何许妙招？
TDD（Test Driven Development），即测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。
测试驱动开发的基本过程如下：
① 快速新增一个测试
② 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
③ 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法
④ 运行所有的测试，并且全部通过
⑤ 重构代码，以消除重复设计，优化设计结构
简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。
可想而知，测试驱动开发会极为有效地控制开发中的bug，但是这种先写测试代码的方式可能让开发人员有很大的不适应。学习适应TDD的成本会不会比它带来的收益更高呢？这就有待我们在实践中摸索了。
5. 第11章 软件设计与实现 —— 11.2 开发阶段的日常管理 —— 11.2.2 每日构建
这一小节中提到了每日构建的重要性，那么，什么是每日构建？
软件开发是一种集体活动，其中必然面临各成员间的协调、统一问题。银行每天都要对各网点进行清算结账，软件开发也是一样的，必须找到一种方法来衡量每天的工作，保证每天的工作能够有效的持续下去，最终把软件开发的过程变成一种内在的过程。这种方法就称为每日构建或是持续集成。每日构建构建的过程是完全自动化的，通过预先定义好的指令，机器将按照指令顺序执行完所有的构建步骤。它让开发者可以每天进行系统集成，从而减少了开发过程中的集成问题。持续集成可以减少集成阶段"捉虫"消耗的时间，从而最终提高生产力。它使得绝大多数bug在引入的同一天就可以被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。对开发人员而言，每日构建带来的好处就是签入即更新。
每日构建虽然会花费一些额外的时间，但是比起最后除错的成本来说，日构建成本是微不足道的。而且更为关键的是能够引入日构建的制度，开发人员将会在日构建的制度下更加频繁的协作，开发进度一目了然，软件的质量也会更加的稳定。软件开发是一项强调沟通和协作的活动，但是在日常的活动中，常常出现阻碍沟通的情况。日构建每一次的构建将会涉及到团队中的所有成员，因此能促进成员的沟通。
在每日构建的驱动下，项目的进度将会变得非常的明显。每一天的构建结果将会通过某个渠道发布出来，团队和团队的老板可以看到软件现在的样子，项目的完成情况，出现的问题等等。这些信息构成了软件开发的基本信息。不但可以清晰地描述出项目进度，也为管理人员安排计划提供了基础数据的支持。有了基本的量化数据，软件开发才不是靠拍脑袋出成果的。
每日构建的最后一个价值是提供了整合性。目前软件开发中并没有一种统一的管理软件，未来似乎也很难做到，因为不同的软件组织差异很大。在开发过程中，一些有价值的实践被加入、集成到每日构建的过程中，在每日构建的推动下，这些优秀实践很容易成为开发过程的一部分。
每日构建的工具有很多，但是最基础、最广泛的工具是Ant（http://ant.apache.org）。