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

Posted 20179215袁琳

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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. 从软件构件方面扩展

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

以上是关于2017-2018-1 20179215《构建之法》第二章的主要内容,如果未能解决你的问题,请参考以下文章

20179215 《构建之法》第三章

2018--20179215--《构建之法(第三版)》第四章 两人合作

2017-2018-1 20179215《Linux内核原理与分析》第十二周作业

2017-2018-1 20179215 《从问题到程序》第一章

2017-2018-1 20179215 《从问题到程序》第五章

2017-2018-1 20179215 《文献管理与信息分析》第一章