世道变了，软件大神都叛变了，向AI投降了......

回顾我这20来年的码农生涯，如果在编程领域找一本对我影响最大的书籍，应该是这一本：

这本书挂着敏捷软件开发的“羊头”，卖的却是面向对象设计的“狗肉”。

它讲了很多设计模式，但是我认为它最精华的部分其实是那个“薪水支付案例”，这个例子让我第一次真正地体会到软件在做设计时，如何做出正确的抽象，发现变化并且封装变化，针对接口编程，组合优于继承。

在我的印象当中，可能只有《Head First Pattern》中的例子能和它比一下，但是无论是复杂度，还是真实感就差太多了。

这种抽象的思想，不是某个编程语言（C++）所独有的，而是所有编程语言都共通的。

这本书的作者，叫做Robert Martin, 人称Uncle Bob（Bob大叔）。

Bob 大叔应该是这个世界上最古老程序员之一，他从1968年开始接触计算机，通过打孔卡和纸带在在 IBM 1401 以及 PDP-8 等早期机型上编写程序。后来用汇编、C语言、Fortran、COBOL等语言进行开发。

80年代末，Bob 大叔接触到C++ 和面向对象的思想，经常泡在“论坛”和人“吵架”，争论如何写面向对象的程序，聊来聊去就总结出一些原则，例如SRP、ISP、DIP、OCP ，最终形成了著名的SOLID原则。

Bob 大叔还有一个非常知名的书，叫做《Clean Code》，如果说上一本是“道”的话，这一本就是“术”，主要是把SOLID和重构落地，写出漂亮代码。

Bob 大叔还是敏捷宣言的24位发起人之一，对TDD和重构非常推崇。

简单来说，Bob 大叔过去几十年所做的一切，都是为了把系统设计得更好，把代码搞的更好阅读，更容易维护。

但是，这样一位一辈子追求Clean Architecture、Clean Code的面向对象的祖师爷，面对AI的威胁和攻击，竟然能“叛变”了！

01

大神的背叛

7月23日，他发了一条帖子，说AI写的代码他一行都不看。

你能想象吗？这样一个面向对象编程的“祖师爷”，对代码有“洁癖”的编程大师，竟然不看代码了。

那这些代码看都不看，如何保证正确性呢？

Bob大叔的做法是给AI施加重重限制，确保糟糕的代码无法通过验证。

第一道防线，是验收测试。

很多时候他会用 Gherkin 这种接近自然语言的格式来写，比如：

Feature: 用户登录

Scenario: 用户输入正确密码登录成功

Given 用户打开登录页面

When 用户输入正确的用户名和密码

Then 用户应该进入首页

这样面向业务的验收测试，主要解决一个问题：软件到底应该干什么，先说清楚。

第二道防线，是单元测试。

它负责盯住代码里的“小零件”，一个函数应该怎么工作，一个模块应该返回什么结果，都提前写好测试。

配合较高的测试覆盖率，可以保证软件不是“看起来能跑”，而是真的有大量行为被验证过。

比较有意思的是第三个：突变测试（Mutation Testing）。

测试工具会偷偷改你的代码，把 > 改成 <，删掉一行代码，故意制造一个小 bug，然后重新运行测试。

如果测试还能全部通过，说明什么？说明你的测试可能只是“摆设”！

还有一类检查，是从外部观察软件质量。

不是打开代码一行行看，而是看它最终表现出来的指标，比如：

• 测试覆盖率

• 依赖关系是否混乱

• 模块是不是越来越庞大

• 圈复杂度

如果一个函数的复杂度达到 40，通常意味着：这里面的逻辑已经像一团打结的耳机线。

不用读完整段代码，只看这个数字，就知道它未来维护起来会很痛苦。

这些方法有一个共同特点：它们都可以被机器自动检查。

机器负责每一次提交、每一次构建、每一次 AI 生成代码后自动执行，机器不会疲劳，更不会因为看到第499行代码开始走神。

总之，Bob大叔认为：要想获得 AI 的高生产力，人类必须从代码细节中解脱出来，从更高级别进行管理。

说实话，看到Bob 大叔的这些言论，我觉得他背叛了他一手教导的广大程序员。

因为他在《Clean Code》里面一直强调：软件大部分时间是在阅读，而不是编写。结果现在他说：我不读 AI 写的代码。

我觉得这种“背叛”的理由有两个：

1.AI生成代码的速度远远超过了人类阅读代码的速度。

既然都看不过来了，还不如去关注测试！

2.他可能在给自己的课程传播造势

Bob 大叔自己有一门课《Clean AI: Agentic Discipline》

这门课讲的就是如何利用 AI 进行高效软件开发，并建立自动化纪律以在不人工逐行审查代码的情况下确保项目质量。

Bob 大叔抓住了 AI 编程时代一个真实存在的问题，然后用一个极具传播性的观点，把自己的解决方案包装成新的软件工程方法论。

02

测试能保证正确性吗？

答案是：不行。

因为测试只能验证“你想到的问题”，无法验证“你根本没想到的问题”。

举个例子，AI 写一个优惠券系统，需求：用户领取优惠券，下单时可以抵扣金额，满100减20

你可以写很多测试，例如：

测试1：正常使用优惠券

测试2：优惠券过期

测试3：优惠券只能使用一次

测试4：优惠券金额不能超过订单

。。。。

所有测试通过，大家会觉得这个优惠券系统没问题。

半年后，产品突然增加一个需求：一个订单可以同时使用优惠券和积分。

现在问题来了，是先扣积分还是先用优惠券呢？

如果先扣积分，订单100元，先扣积分30元，剩70元，没法用优惠券了。

你如果事先想到了这种情况，可以和产品商量好业务规则，通过测试把它确定下来。

如果你想不到，那虽然所有测试都通过，系统上线后肯定会有用户投诉了。

过了两年，公司的业务又变化了：“双11活动，所有订单额外打九折。”

你需要把订单的各种情况都考虑到，保证没有问题才行。

那我有没有可能事先把所有情况都考虑到，然后把它们用测试覆盖？

这是软件工程里一个非常经典的问题。

一个简单的答案是：理论上可以，实际上几乎不可能。

只有非常简单、状态空间有限的软件，才可能做到“穷尽测试”。

现实是非常非常复杂的，再拿订单系统举例，会有各种各样的：

用户状态：普通用户、VIP用户、黑名单用户、新用户、老用户......

优惠方式：无优惠、优惠券、积分、会员折扣、活动折扣......

这还不算： 网络失败 、 数据库异常 、OOM、 并发 、 超时 、 重试 、 用户重复点击、秒杀.....

各种各样的状态、条件、环境搅在一起，数量会发生爆炸。

人是无法事先把所有的情况都考虑到的，所以无论软件写得多么好，测试多么充分，最后还是有Bug。

为了控制这种复杂度，Bob 大叔教我们使用Clean Architecture、SOLID、Clean Code，教我们如何设计架构，组织整个软件，怎么写出干净的代码，让它长期可维护。

现在Bob 大叔竟然不看代码了，只关注外界的测试和约束，真不知道他是怎么想的。

另外一个面向对象的大师级人物，UML创始人之一，也曾经对Bob 大叔有重大影响的Grady Booch 也不同意Bob的看法。

他说： 测试覆盖率和类似指标可以让我相信这些功能是正确的，但它们完全无法让我相信Agent没有引入糟糕的设计和隐藏的漏洞，对于AI生成的代码，要Trust ,but Verify

03

在《敏捷软件开发：原则、模式与实践》中有一节，标题是“源代码就是设计”，着实让我震惊不已。

测试看到的其实是“软件行为”，代码承载的才是“软件设计”，其中包含大量数据模型、模块边界、复杂度控制、未来变化的能力，这些东西，不一定能通过测试发现。

现在Bob 大叔不再阅读源码，那就是不再阅读设计了，难不成现在他认为测试和约束才是设计了？

最后，欢迎在评论区说说你的看法：AI生成的代码，你会看吗？