《构建之法》第2章 个人技术和流程

《构建之法》第2章 个人技术和流程

本章的理论和知识点主要有:单元测试，回归测试，效能分析，个人软件开发流程（psp）

一、单元测试：

单元测试作为一种解决方案，让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定、量化的保证。

1.1用VSTS写单元测试

1.2 好的单元测试的标准

一个好的单元测试，应该准确、快速的保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：

• 单元测试应该在最基本的功能/参数上验证程序的正确性。
• 单元测试必须由最熟悉代码的人（程序的作者）来写：代码的作者最了解代码的目的、特点和实现的局限性。
• 单元测试过后，机器状态保持不变：这样即可保证单元测试不断的运行，如果创建了临时的文件或目录，应该在Teardown阶段删掉。
• 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
• 单元测试应该产生可重复、一致的结果。
• 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性：程序中的各个模块是相互依赖的，一般情况下单元测试中的模块可以直接引用其他的模块，如果其他的模块很不稳定，或者其他的模块运行比较费时，而且对于本模块的正确性并不起关键作用时，可以认为的构造数据，以保证单元测试的独立性。
• 单元测试应该覆盖所有代码路径。
  
  注意:100%的覆盖率并不等于100%的正确性。
• 单元测试应该集成到自动测试的框架中，这样每个人都能随时、随地运行单元测试。
• 单元测试必须和产品代码一起保存和维护。

1.3 回归测试

• 回归是指模块出现了一个退化，从正常状态回归到以前不正常的状态。能避免遗漏bug，以及确保bug都已解决。
• 回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽快发现问题。单元测试是回归测试的基础。
• 针对一个bug修复，也要进行回归测试，目的是：
  1.验证新的代码的确改正了缺陷。
  2.同时要验证新的代码有没有破坏模块的现有功能，有没有regression。

二、效能分析工具

通过效能分析工具，尽快找到程序的效能瓶颈，从而进行程序的改进。通过“效能测试，分析，改进，再效能测试”的流程，逐渐提高程序的效能和我们的编程水平。

可以选择两种分析方法：

• 抽样：当程序运行时，时不时看一看这个程序运行在哪一个函数内，并记录下来。抽样的运行较快，可以很快的找到瓶颈，但是不能得到精确的数据，也不能准确表示代码中的调用关系树。

• 代码注入：将检测的代码加入到每一个函数中，这程序的一举一动都被记录在案，程序的各个效能数据都可以被精确地测量。但运行时间大大加长，还会产生很大的数据文件，也相应增加了数据分析的时间。

一般的做法是，先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方法进行详细分析。

三、个人开发流程

通过大学生和工程师的psp数据比较，我们可以看到从学生到职业的程序员，花在写代码上的时间反而少了许多，更多时间用在“需求分析”和“测试”这两方面。

psp特点：

• 不局限于某一个软件技术（如编程语言），而是着眼于软件开发的流程，这样开发不同应用的软件工程师可以相互比较。
• 不依赖于考试，而主要靠工程是自己手机数据，然后分析，提高。
• PSP依赖于数据，需要工程师输入数据，记录工程师的各项活动，再加上数据不准确或者有遗失。
• PSP的目的记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度。

总结：

  通过本章的学习，我学会了一种思想，在学好代码的同时，要运用好单元测试和效能分析，有效的优化代码，提高效率，并保证模块的质量更加的稳定和量化。但是具体如何进行单元测试和效能分析，还需要进一步的学习体会。