修改代码的艺术-读书笔记

修改代码的艺术.jpeg

前言

1. 遗留代码：没有编写相应测试的代码。P2

第一章 修改机理

1. 修改软件的四个原因：P3

• 添加新特性
• 修正bug
• 改善设计
• 优化资源使用

2. 减少代码修改风险，考虑三个问题：P6

• 要进行哪些修改
• 如果得知已经正确地完成了修改
• 如何得知没有破坏任何(既有的)东西

3. “避免”修改带来的问题：P6

• 在现有方法添加，绝不创建新类或方法，现有类和方法就越来越大，越来越难理解
• 久而久之会对代码感到生疏
• 会带来恐惧心理。害怕修改造成系统错误，所以采取“鸵鸟战术”，但是系统每况愈下，变得臃肿庞大无法理解了，恐惧就来了。

第二章 带着反馈工作

1. 修改并祈祷：花额外的时间验证是否真的把事情做对了 P9
2. 覆盖并修改：使用测试作为安全网，然后在修改 P9
3. 一个需要耗时十分之一秒才能执行完的单元测试就已算是一个慢的单元测试了 P11

• 3000个类，每个类10个测试，总共30000个测试，每个十分之一秒，全部要花将近1个小时

4. 不是单元测试： P12

• 跟数据库有交互
• 进行了网络间通信
• 调用了文件系统
• 需要对环境做特定的准备才能运行

5. 高层测试也是有意义的，一个测试就能确定一组类的行为 P12
6. 依赖性是软件开发中最为关键的问题之一。在处理遗留代码的过程中很大一部分工作都是围绕着“解除依赖性以便使改动变得更容易”这个目标来进行的 P14
7. 遗留代码的困境：我们在修改代码时，应当有测试在周围“护”着。而为了将这些测试安置妥当，我们往往又得先去修改代码 P14
8. 遗留代码修改算法：P15

• 确定改动点
• 找出测试点
• 解依赖
• 编写测试
• 修改、重构

第三章 感知和分离

1. 使用伪对象编写测试：mock object P26

第五章 工具

1. 如果有一个工具，它能够替你完成重构工作，那么我们会倾向于认为无需为待重构的代码编写测试 P41

第六章 时间紧迫，但必须修改

1. 为新功能添加测试 P52