2017-2018-1 20179215《构建之法》第二章

《构建之法》第二章读书笔记

2.1 单元测试

软件是由多人合作完成的，不同人员的工作相互有依赖关系。例如，一个人写的模块被其他人写得模块调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方法。

 2.1.1 用VSTS写单元测试

 2.1.2 好的单元测试的标准

• 单元测试应该在最基本的功能/参数上验证程序的正确性。
• 单元测试必须由最熟悉代码的人（程序的作者）来写。
• 单元测试过后，机器状态保持不变。
• 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
• 单元测试应该产生可重复、一致的结果。
• 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
• 单元测试应该覆盖所有代码路径。
• 单元测试应该集成到自动测试的框架中。How？
• 单元测试必须和产品代码一起保存和维护。

 2.1.3 回归测试

针对一个Bug Fix，我们也要做Regression Test。目的是：

1. 验证新的代码的确改正了缺陷
2. 同时要验证新的代码有没有破坏模块现有的功能，有没有Regression

2.2 效能分析工具

两种分析方法：

1. 抽样
2. 代码注入

如果我们不经分析就盲目优化，也许会事倍功半。

2.3 个人开发流程

1. 计划
   *估计这个任务需要多少时间

2. 开发

   *分析需求

   *生成设计文档

   *设计复审（和同事审核设计文档）

   *代码规范（为目前的开发制定合适的规范）

   *具体设计

   *具体编码

   *代码复审

   *测试（包括自测，修改代码，提交修改）

3. 记录用时

4. 测试报告

5. 计算工作量

6. 事后总结

7. 提出过程改进计划

2.4 实践

• 单一职责原则：一个模块应该只有一个导致它变化的原因，一个模块应该完全对某个功能负责。
• 开放-封闭原则：软件实体应该是可以扩展的，同时是不可修改的。
• 简单的程序从几个维度逐步扩展，增加复杂度。
  1. 从数据方面扩展
  2. 从需求方面扩展
  3. 从用户方面扩展
  4. 从软件构件方面扩展

这章主要让我认识到测试的重要性，现在我们主要是编写代码，并没有考虑到代码效率，执行时间等等问题，我记得在《从问题到程序》第四章笔者也谈过这个问题，不过他是提供一个时间函数可以方便我们计算复杂度，其实测试的目的也在此，特别是对于团队开发中各个模块的测试，一个细小的改变可能就会大幅度提高效率。