构建之法读书笔记 第2章 个人技术和流程

构建之法读书笔记 第2章 个人技术和流程

本来打算每天看一章的，奈何平时搬砖没时间，周末有时间了就想过咸鱼生活，还是得提高一下自制力。回想一下近些日子很少读书了，纸质小说没看，今年年初kindle下了一堆小说，都放没电了还只看了本东野的<>，现在连剧情都回想不起来了，整天被公众号UC文的碎片化信息充斥，感觉整个人都浮躁，无聊，可能真的需要读书充电了。

• 相关概念： PSP(Personal Software Process)个人软件开发流程，与喜闻乐见的PSP游戏机名字一样

2.1 单元测试

• 自己负责的模块应该做到功能定义尽量明确，低耦合，模块内部的改变不会影响到其他模块，且模块的质量应该稳定，这是多人合作完成软件构建的基础。为了达到这个目的，单元测试是一个有效的解决方案。

• VSTS 工具写单元测试部分，我对C#语言没有了解，也没有用过VSTS工具，在python中使用

  if __name__ == '__main__':
    do something

  感觉还挺方便的，但是感觉没有书上那么有条理

• 很多调查显示，在软件开发后期发现的Bug，修复起来要花更多的时间。

  • 以我目前的体验来说，不要说软件了，平时几个有调用关系的函数如果其中一个没写对，找bug就很麻烦，与其debug的时候把变量打印出来，还不如写好一个函数就去测试，只不过明白这个道理但总是犯懒，在debug上反而花了更多精力。

• 好的单元测试标准

  • 在最基本的功能/参数上验证程序的正确性
    • function, class 中的成员函数及其参数
  • 单元测试应由作者来写（对代码最熟悉）
  • 测试后机器状态保持不变（临时文件需要删掉）
  • 测试应该快，每个模块独立测试（只修改了用户界面代码，则只运行用户界面的单元测试）
    • 这样应该在写模块的时候就模块的功能就应该分得尽量清晰，方便测试
  • 单元测试应该是可重复的（使用不可复现的真随机数不可取，意义不大）
    • 书中提到不必期望单元测试能够发现所有的缺陷
  • 单元测试的结果不应该依赖于别的测试
  • 单元测试应覆盖代码的所有路径(if...else, switch等分支都应该测试，还有错误处理路径)，保证代码覆盖率
    • 100%覆盖率 != 100%正确性（还有要考虑是否正确释放内存，效率问题等）
  • 单元测试应该集成到自动测试的框架中去
    • 感觉测试好复杂
  • 与产品一起保存和维护
    • 保证单元测试和代码的一致性，防止单元测试滞后于代码本身，这样单元测试就无效了

• 回归测试(Regression Test)

  • Regress: 模块从正常工作的稳定状态退化到不正常工作的不稳定状态。
  • Baseline: 模块的功能基准线，一个模块的所有单元测试就是模块最初的baseline
  • 对于一个Bug Fix， 也要做Regression Test
    • 目的: 验证新的代码中改正了缺陷，验证新代码是否破坏了模块的现有功能
    • 自己总结一下就是: 验证代码本身正确，验证与其他部分的一致性

效能分析工具

• 两种分析方法
  • 抽样
    • 当程序运行时，时不时看看这个程序运行在哪个函数内
    • 不用改程序，运行快，找瓶颈方便
  • 代码注入
    • 将检测代码加入到每个函数中，精准测量效能数据
    • 增加程序运行时间，产生很大的数据文件，注入的代码影响真实运行情况
  • 一般做法: 先抽样找到瓶颈，再对特定模块使用代码注入
• Visual Studio 的效能分析工具
  • 以前再学校的软工课上简单的使用过，其实当时也就光看看热行。而本书上的表把各个概念解释的挺清楚的，当时没怎么关注这些概念。

个人开发流程

这节的图表看不太进去，感觉体会到的就是在开发过程中不光要分析软件本身，也要分析自己吧，提高自己的效率吧。

转载于:https://www.cnblogs.com/QiLF/p/11439565.html