最近我观察到一个现象：人们使用AI，大多是用来生成新代码。新代码容易测试，对吧？AI非常擅长这件事，于是成千上万个测试被创建出来，而且绿得漂亮。 但并不是所有人都只写新代码。我们中的大多数人面对的是遗留系统、棕地项目——多年荒废、堆满糟糕决策，而且，没有测试。 业务方不在乎这些。高管们只想要那个功能，他们无法理解为什么这么难。可事实是，我们动了一个地方，另一个地方就坏了。我们让AI去干一件事，它却会碰更多不该碰的东西！ 那我们还能做什么？人们常常跳到一个结论：“重构”——“如果我把代码写得更好，就能实现新功能了。”别误会，这个想法本身是金点子，但往往经不起现实检验。重构困难重重、容易出错，而且不带来任何短期价值，只有风险。 那么，我们直接让AI为现有代码写测试，行不行？可以是可以。但有用吗？没用。 你可能会问：为什么？因为遗留代码本身就是问题重重的——它纠缠不清，经常把不同层次和职责混在一起。如果你让AI去测试它，它一定会搞错。测试会和具体实现耦合在一起，因为猜猜怎么着？有人在业务逻辑里直接访问数据，有人一边计算金额一边创建事务范围，还顺手持久化了一笔支付。这种事经常发生。 那解决方案是什么？如果我们换一个思路，让AI从上到下、以“活代码”的方式去运行和验证，而不是纠结于每个单元的测试、模拟依赖、把断言绑定到实现上（那会限制你的重构能力），为什么不直接让AI写特征测试（characterization tests）呢？ 为什么AI特别擅长帮你写特征测试？ 我的看法是：在有人验证之前，AI写的东西都是错的。而验证往往比亲自写代码还难！这正是我无法完全信任AI去写那些“没有测试”的生产代码的原因。 但我们让AI写特征测试就不一样了——它不是在写生产代码！风险低多了。你可能会说：如果……

打开网易新闻 查看精彩图片