本文适合：写出代码却不敢改的开发者、从不写测试的"裸奔选手"、想提升个人工程素养的同学。
你将收获：单元测试的8条黄金标准、回归测试的实战意义、效能分析的两板斧、PSP个人软件过程的认知升级。
写在前面
第一章告诉我们软件=程序+软件工程，但"软件工程"到底怎么落到个人头上？第二章就是回答这个问题：在你还没带团队、还没管项目之前，作为一个人，你能做什么？
答案是三件事：写好单元测试、用好效能分析工具、建立自己的开发流程（PSP）。
听起来朴素，但读完才发现，自己过去几年在这三件事上犯了太多低级错误。
01 | 单元测试：你的代码"敢改"吗？
1.1 为什么需要单元测试
书中提了一个直击灵魂的问题：如何让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？
答案就是单元测试。
这个问题之所以重要，是因为绝大多数软件都是多人协作的。你写的模块被别人调用，别人的模块也被你调用。如果没有单元测试，每次改代码就像拆弹------你不知道剪哪根线会炸。
1.2 好的单元测试：8条黄金标准
书中给出了判断单元测试好坏的8条标准，我逐条标注了自己的"踩坑指数"：
|------------|------------------|------------------------------------|
| 序号 | 标准 | 我的踩坑经历 |
| 1 | 在最基本的功能/参数上验证正确性 | 以前只测"正常流程"，边界条件全靠用户在线上帮我测 |
| 2 | 必须由最熟悉代码的人（作者）来写 | 把测试全丢给测试团队，结果测的都是表面功能，深水区的bug一个没覆盖 |
| 3 | 测试过后机器状态保持不变 | 写过创建临时文件不清理的测试，跑两次就报错，排查了一下午 |
| 4 | 要快（几秒而不是几分钟） | 有个测试连接真实数据库，每次跑30秒，最后大家都不愿意跑了 |
| 5 | 产生可重复、一致的结果 | 依赖网络API的测试，断网就挂，时好时坏，最后沦为"薛定谔的测试" |
| 6 | 独立性------不依赖别的测试 | 测试B依赖测试A先跑完创建的数据，换台机器顺序一变全崩 |
| 7 | 覆盖所有代码路径 | 以为覆盖了主流程就够了，结果异常分支里的bug上线后才暴露 |
| 8 | 和产品代码一起保存和维护 | 测试代码放在个人电脑里，人一离职，测试全没了 |
注意：100%的覆盖率 ≠ 100%的正确性。 覆盖率只是必要条件，不是充分条件。你的测试可以"跑过了"每行代码，但如果断言写得不对，等于没测。
1.3 回归测试：bug修了，别再"复发"
回归测试的核心目的有两个：
验证新代码确实修复了缺陷
验证新代码没有破坏现有功能（没有引入Regression）
书中强调：回归测试最好自动化。因为只有自动化，才能对每个构建快速运行所有测试，尽早发现问题。单元测试是回归测试的基础。
我的实战感悟
有一次线上紧急修bug，改了10行代码，测试通过就上线了。结果第二天用户反馈另一个功能挂了------因为改的那10行代码影响了一个共享函数，而那个函数被另一个模块调用。如果我们有完整的回归测试，这个问题在构建阶段就能被发现。
从那以后我定了一条规矩：改任何共享代码，必须跑全量回归测试，没有例外。
一句话提炼
单元测试不是"写完代码再补"的装饰品，而是"写代码时同步铸就"的安全网。它的价值不在你写的时候，而在你改的时候。
02 | 效能分析工具：别盲目优化
2.1 两种分析方法
书中介绍了两种效能分析方法，对比很清晰：
|------------|------------------------|---------------|-----------------|--------------|
| 方法 | 原理 | 优点 | 缺点 | 适用场景 |
| 抽样 | 程序运行时不时"看一眼"在哪个函数，记录下来 | 运行快，不改动代码 | 数据不精确，无法得到调用关系树 | 快速定位瓶颈所在 |
| 代码注入 | 把检测代码加入每个函数，记录一举一动 | 数据精确，能测量各效能指标 | 运行时间大幅加长，数据量大 | 对特定模块深入分析 |
推荐策略：先抽样找瓶颈，再代码注入做精细分析。 这就像体检------先做整体筛查，发现哪有问题再做专项检查。
2.2 最重要的一句话
书里有一句话我划了重点：要避免没有分析就过早地进行"效能提高"。如果不经分析就盲目优化，也许会事倍功半。
我的血泪教训
这简直是写给我看的。之前有个接口响应慢，我凭直觉花了两天重构了一段"看起来效率不高"的代码，结果性能毫无变化。后来用效能分析工具一跑，发现瓶颈根本不在那里------是数据库查询没加索引，一个查询扫了全表。
两天白干，就因为没先分析。
从此我给自己定了个流程：优化前先测量，测量后先定位，定位后再动手。三个步骤缺一不可。
一句话提炼
"先测量，再优化"不是建议，是铁律。凭直觉优化代码，和蒙着眼睛开枪没区别。
03 | 编程练习和成长
3.1 PSP：个人软件过程
书中介绍了PSP（Personal Software Process），这是一套让个人开发者量化自己工作过程的方法。
PSP的几个特点：
不局限某一种技术：着眼于开发流程，不同语言/平台的工程师可以横向比较
靠数据驱动：工程师自己收集数据、分析数据、改进流程
记录的是效率，不是满意度：PSP关注"你怎么实现需求"，不关注"客户喜不喜欢"
书中有一个很有意思的对比：大学生和工程师的PSP数据。结论是------从学生到职业工程师，花在"写代码"上的时间反而少了，更多时间花在"需求分析"和"测试"上。
这个数据打破了我的一个认知盲区：我以前总觉得"高级工程师 = 写代码快的人"。但实际上，高级工程师写得不一定更快，而是在不该写的时候不写------先分析需求、先写测试、先做设计，磨刀不误砍柴工。
3.2 PSP的局限
书中也坦诚提到了PSP的问题：
依赖工程师手动输入数据，容易遗漏或不准确
需要持续记录，对自律性要求很高
数据质量直接影响分析结论的可靠性
这让我想到自己试过几次"记录时间开销"，每次都是头三天认真记，后面就忘了。PSP的难点不在方法本身，而在坚持。
一句话提炼
高级工程师的核心能力不是"写得快"，而是"知道什么时候不该写"。PSP帮你用数据看清自己的时间花在了哪里。
干货复盘
|----------------|---------------|--------------|
| 本章核心概念 | 一句话理解 | 常见误区 |
| 单元测试 | 写代码时同步铸就的安全网 | "写完再补测试" |
| 回归测试 | 确保修bug不引入新bug | "改了一点不用全测" |
| 效能分析 | 先测量再优化 | 凭直觉盲目优化 |
| PSP | 用数据量化自己的开发过程 | 只记三天就放弃 |
今日最大收获： 软件工程不是从"带团队"开始的，而是从"写第一个单元测试"开始的。个人技术和流程，是整个软件工程体系的基石。没有个人的工程素养，再好的团队流程也是空中楼阁。
下次分享第三章：软件工程师的成长。如果这篇笔记对你有帮助，欢迎转发给也在学软件工程的朋友。