测试越写越多：先看是不是一个模块干了太多活

我重写过两个系统，两次都碰上测试长得比代码还快。第一次我直接删测试；第二次才想到去看：是不是一个模块干了太多活。

测试多不多，和改起来累不累是两回事

有一次重构，旧版的核心文件几千行，被几十处检查依赖着；新版把同样的功能拆成三个分工清楚的模块。

测试的总量基本没变，但改一个地方要跟着改的测试少了一大半。省下来的是连带修改，不是靠删测试。

职责一混，牵连就乘起来

一个模块又解析输入、又推进状态、又管输出格式，动哪一块都可能影响好几组测试。把这几件事分开、接口稳住，改一处才能只测一处。

光把大文件拆成小文件没用。模块之间还是互相读内部字段、共享一堆可变状态的话，依赖只是换了个地方住。

数一个数就够了

我会看：改这个模块，要同步改多少测试、接口和调用方？这个数比看总行数、测试总数都更能指出哪里耦合太紧。

不过牵连多也可能是测试写得太贴着实现，一步一步复制内部逻辑，而不是测对外的行为。这种就该改测试了。

我的顺序是先理职责和依赖，再收拾那些又脆又重复的测试。该测的都还在，改起来不用牵一发动全身，这才是重构的收益。