有说法称“通过耦合设计为客户端生成代码是不好的事情”，为什么这么说？

在分布式领域，我们曾经试图用 RMI, rpc 模型简化跨系统调用，表面上使用起来像本地的方法调用一样，背后发生在网络两端两个不同的进程之间。但事实并不是这样的，本地的调用是非常快速，而且进程内调用不太可能出错，但是跨网络调用有很多网络开销，包括时延、乱序、丢包，所以是不稳定的。

使用客户端生成代码的实践，是试图把分布式调用去伪装成一个本地的调用，从客户端角度来说，去远程调用和本地调用，好像没有任何区别，都是做一些方法调用，但其实屏蔽和忽略了很多网络调用中的复杂度和错误处理。

另外这种实践也会在 API 发布者和消费者之间的系统引入静态耦合。如果 API 发布方接口发生了变化，往往需要重新发布客户端 SDK，而消费方不得不重新编译、部署和升级。因为这是一个非常强的程序静态编译层面的耦合。

我们完全可以采取更加动态松耦合的集成方式，不要过于依赖 IDL 提供的虚幻的类型安全。如果发布者 API 发生了变化，只要消费端宽容读者的模式 (tolerant reader pattern)，可以对 API schema 变化有比较高的适配，不需要重新做部署升级。我们仍然可以使用消费者驱动契约测试 (Consumer Driven Contract Test) 等方式保证 API 的变化是安全的。