第二章：个人技术和流程
要点： 单元测试，回归测试，效能分析，基于个体的软件开发流程(PSP)
单元测试的构建标准：
- 应当验证基本的组件，典型的就是类
- 应当由程序编写者编写测试
- 测试过后机器状态不变，测试过程中的变化必须在完成后恢复，比如将生成的文件删除（这就是tearDown方法要做的事情）
- 测试要快
- 可重复、结果一致
- 独立性， 不依赖于其他测试单元的成败性。为此，可以人为构造一个对象或者数据
- 应当覆盖所有的代码路径
- 应当集成到自动测试框架之中
- 单元测试必须和产品一起维护，保持同步
回归测试：在单元测试的基础上，当新版本发布时，工程师必须再次运行所有的测试。
效能分析：使用效率分析工具对代码进行抽样和注入两种形式的分析，先进行抽样调查，找到性能瓶颈代码，然后使用注入分析瓶颈代码块，进行优化。
PSP
- 计划
-- 估计任务需要花费的时间 - 开发
-- 分析需求
-- 生成设计文档
-- 设计复审（和同事复审）
-- 代码规范（为开发制定合适的规范）
-- 具体设计
-- 具体编码
-- 代码复审
-- 测试 - 记录用时
- 测试报告
- 计算工作量
- 事后总结
- 提出过程改进计划
第四章 两人合作、代码复审...
这一部分有关于C++代码规范、通用代码风格、通用代码复审的说明
注释： 应当说明代码做什么以及为什么，而不是怎么做（How）。
(Bad)How：
// loop starts i from 0 to len, in each step, it does something
for(int i=0;i<len;i++)
{
doSomething(i);
}
上述注释不好的原因是，它说明了代码的执行流程，但是对于实际的作用却没有任何说明，相反，良好的注释应当如下：
// transfer the array into a list
for(int i=0;i<len;i++)
{
doSomething(i);
}
复审
形式：自我复审、同伴复审、团队复审(团队vs开发者)
复审的基本含义：1.代码符合代码规范的框架 2.代码解决了问题
基本步骤：1.保证所有的代码能通过统一的警告级别（如gcc -W1|2|3）...
代码复审的基本工具：元注释
在代码中出现 // TODO 形式的注释，这些注释适用于代码复审的，并且有一些要求：
- 在发布阶段，// TODO , // BUG 应当被消除
- 在复审阶段， // REVIEW 应当被消除或者标记
第八章： 需求分析
软件需求的划分：1.功能性需求，说明软件应当完成的功能 2.产品开发过程的需求，需要在某种约束条件下完成，比如时间，金钱 3.非功能性需求，也称QoS，规定完成功能的时间或者其他约束 4.总和需求，多个模块一起工作的需求
计划和估计：必须对计划进行合理的时间估计
第九章：PM -- 项目经理
Project Manager v.s. Program Manager
早期软件开发过程中，内部交流的代价随着人员的增加而急剧上升。PM的出现就是为了解决交流的问题。
现在，PM主要具有以下功能：
1.和客户交谈，组织用户调查，发现用户需求
2.了解和比较竞争产品
3.怎样让软件变得可用、有用
4.改进团队流程
简言之，PM做除开发和测试之外的所有事情
第十章 典型用户和场景
第一种分析方法： 分析典型用户，分析典型用户涉及的典型场景
第二种分析方法：Use Case， 即用户用例
第三种方法：规格说明书，包括软件功能说明书和软件技术说明书
为了写好功能说明书，必须先定义好一些概念。
