这次个人阅读选择的书籍为《构建之法：现代软件工程》（邹欣 著）。我们这门课程也参考了很多这本书的结构、内容与方法，读这本书，既是对学过知识的复习和细化，也是对以后课程的预习。
下面总结了几个阅读过程中理解有困难或疑问的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 敏捷的故事
这一小节提到了几种比较出名的敏捷开发方法论，如FDD、Scrum、XP、TDD。前三者在书中都有专门的介绍，但TDD，久闻其大名，到底是何许妙招？
TDD（Test Driven Development），即测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。 测试驱动开发的基本过程如下： ① 快速新增一个测试 ② 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过 ③ 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法 ④ 运行所有的测试，并且全部通过 ⑤ 重构代码，以消除重复设计，优化设计结构简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。
可想而知，测试驱动开发会极为有效地控制开发中的bug，但是这种先写测试代码的方式可能让开发人员有很大的不适应。学习适应TDD的成本会不会比它带来的收益更高呢？这就有待我们在实践中摸索了。
标签：10,06,断言,sum,笔记,assert,开发,构建,测试 From： https://www.cnblogs.com/Hugo-Martin/p/18227676