构建之法读书笔记 第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 的效能分析工具
- 以前再学校的软工课上简单的使用过，其实当时也就光看看热行。而本书上的表把各个概念解释的挺清楚的，当时没怎么关注这些概念。
个人开发流程
这节的图表看不太进去，感觉体会到的就是在开发过程中不光要分析软件本身，也要分析自己吧，提高自己的效率吧。
