2018-2019-1 20189221 《构建之法》第 2 周学习总结

第 2 章个人技术和流程

单元测试应该准确、快速地保证程序基本模块的正确性。
标准：单元测试应该在最基本的功能/参数上验证程序的正确性。
单元测试应该测试程序中最基本的单元—如在C++/C#/Java中的类，
在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。
从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。

如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，则于事无补。我们还是要用随机数等办法“增加测试的真实性”，但不是在单元测试中。

单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。

单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。

如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。
把所有以前发现并修复的Bug找出来，一个一个验证，以保证所有已经修复过的 Bug的确得到了修复。

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

　　（1）计划（估计这个任务需要多少时间）

　（2）开发（包括分析需求，生成设计文档，设计复审（和同事审核设计文档），代码规范（为目前的开发定制合适的规范），具体设计，具体编码，代码复审，测试（包括自测，修改代码，提交修改））

　　（3）记录用时

　　（4）测试报告

　　（5）计算工作量

　　（6）事后总结

　　（7）提出过程改进计划

工程师在“需求分析”和“测试”这两方面明显地要花更多的时间；但是在具体编码上，工程师比学生要少花1/3强的时间。

不局限于某一种软件技术（如编程语言），而是着眼于软件开发的流程，这样，开发不同应用的软件工程师可以互相比较。
不依赖于考试，而主要靠工程师自己收集数据，然后分析，提高。
在小型、初创的团队中，很难找到高质量的项目需求，这意味着给程序员的输入质量不高。在这种情况下，程序员的输出（程序/软件）往往质量也不高，然而这并不能全部由程序员负责。
PSP依赖于数据。需要工程师输入数据，记录工程师的各项活动，这本身就需要不小的时间代价。
PSP的目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度。