测试驱动开发的春天来了:读《现代软件工程》有感

David这本书出版的非常及时。它覆盖了软件工程比较广泛的话题，也列出了一些基本原则:

模块化，关注点分离，迭代开发，反馈环，增量开发，内聚，松散耦合，可观察性，fail fast。这些原则都是为了克服人类开发软件过程的困难而探索出来的，任何一个人类程序员都可以从中受益。

而我等 AI 软件工程的探子，显然更关注 AI 程序员的缺陷，以及能弥补这类缺陷的工具和原则。

目前AI程序员，相对于人类开发者，有两个很严重的缺陷:

1.缺乏理解需求的常识。比如我曾经让github Copilot去把我公司网站改造为一天自动赚一百万美金的发财网，它就真的二话不说撸起袖子开干了。

2.质量非常不稳定。大多数时候，AI生成的代码比人类质量更高，但是有时候它会生成一些无法直视的垃圾，甚至在一些时候，它会作弊，硬编码不能用的假代码。

对于第一个问题，我已经探索出了方法，但是第二个问题还是比较麻烦的。

David在书中建议了一个很好的方法: 测试驱动开发。

测试驱动就是来控制质量的。根据Spec撰写的测试用例，实际上就是其他成熟工程行业的验收项。测试用例的一次次运行，就是对质量的一次次验证。通过不断的跑测试，我们确保质量一直在水平线以上。

David还指出一点: 测试驱动开发不仅会提升后续开发过程的质量，也会影响前置设计过程的质量。因为不良的设计会导致测试困难，具体就会表现为测试用例极为难写。只有系统设计为清晰的模块，模块之间有松散耦合，并且有较好的内聚性，测试用例才会写的出来。

而且，测试驱动开发是1999年提出的，ThoughtWorks的朋友们扯着嗓子喊了二十多年，在行业的应用仍然举步维艰，仍然属于先锋技术。

这其中的原因是什么？我认为一个很重要的原因是，测试驱动开发对程序员的心智负担太重了。

传统的测试用例是测试implementation的，程序员对着implementation的代码，写出测试用例，经常复用其代码。这是一种很自然的工作，无非就是工作量问题。

但是TDD要求的也是程序员对着spec写测试用例。这个时候，程序员手头有的只是一个需求spec，没有代码，没有流程图，没有接口，要设计出一整套验收标准，并且翻译成测试用例，真的不容易。而你好不容易完成这一部分，项目经理问你”功能实现多少了？”，你只能尴尬的回答”一个功能都没实现”。

AI可以改变这一切。只要有良好的，AI可以在几十分钟内写好测试用例，而不是人类需要的几天。

有了快速的测试用例，我们就可以:

1. 用于和需求方对齐，确保我们实现的是他们需要的。

2.用于检验设计。如果测试用例残缺不全，或者测试无法执行，很可能问题出在系统架构上。

3.用于指导开发。开发implementation的工作变得很简单，就是通过测试用例集。

我有些朋友指出AI写的代码质量，方差太大了，不可用。这是一个很正确的描述。作为工程师，我的工作就是解决这些可以解决的问题。很开心，David Farley提供了方法论帮助我建设这些解决问题的工具。

我建议读者读一下这本书，把您的感想发表在评论区，大家一起交流。