契约式编程与防御式编程

背景

这事儿得从几天前的一次技术讨论说起——关于接口返回数据的处理，以及几个月前关于课件本地数据结构的争论。核心问题其实很经典：当约定好的数据格式出现异常时，我们该在程序内部默默兼容处理，还是干脆利落地抛出错误？

举个具体的例子：我们需要解析一段JSON。按照约定，它的格式要么是标准结构，要么干脆是空值。但如果负责返回JSON的方法，偏偏给了一个“既非标准、又非空”的怪东西，程序该怎么办？

团队里立刻出现了两种声音：

小花主张：“一旦碰到约定之外的异常，程序必须做兼容处理，绝对不能Crash！”

小Fa则认为：“约定外的异常必须立刻抛出，明确告知约定被破坏，这样才能揪出根因。”

相信每位开发者都遇到过类似困境。最常见的“栗子”莫过于NullPointerException。当试图从JSON中取出某个字段却遭遇空指针时，一部分开发者会认定这是数据问题，把数据修正即可；另一部分则认为是程序问题，代码理应做好非空判断再使用。两种思路各有道理：前者代码简洁明了，逻辑干净，但一旦出错，程序便会崩溃；后者程序“耐操”，任你数据怎么错，我自岿然不动，但代价是代码里遍布非空判断，显得臃肿而重复。

生存还是毁灭？这真是个问题。

防御式编程

正当我们争论不休时，一位姓康的同事默默祭出了一块“砖头”——《代码大全2》（近900页，厚度堪比三本《Android群英传》）。起初还以为他要物理说服，结果他翻到了第八章，几个大字赫然映入眼帘：『防御式编程』。

果然是老司机，居然能从“防御性驾驶”悟出“防御性编程”。说好的编程不开车呢？

这位作者编程水平如何暂且不论，但论开车，肯定没有何老师diao！

言归正传，《代码大全》给的定义很直白：所谓“防御式编程”，核心思想就是“人类是不安全且容易犯错的，你写的代码应该预见到所有可能的错误输入，确保程序不会因为别人的错误而崩溃”。

书中提到，程序需要对可能的错误输入做出兼容。例如，一个除法函数，必须判断分母是否为0，并给调用者返回明确的错误提示。此外，高级语言通常提供了『断言』和『异常』两种机制来处理错误。

断言

断言，是一种在开发阶段使用的、让程序在运行时进行自检的代码。断言为真，程序正常运行；断言为假，程序则异常退出。等等，防御式编程不是说要兼容异常吗？怎么反而退出了？实际上，作者的本意是“先断言，后处理错误”，而断言通常只在开发环境中启用，正式上线后会被移除。

但这里存在一个悖论：开发阶段的错误处理代码，可能被断言提前拦截掉了。然而，错误处理代码本身也是人写的，谁来检测“错误处理代码”可能发生的错误呢？

异常

当代码出现问题时，可以通过抛出异常来通知外界。如果你无法处理，就交给上层调用者。这一点大家都很熟悉，最简单的莫过于try-catch。甚至见过有人把整段代码都塞进try-catch里——这得是对人类有多不信任？

所以，防御式编程用久了，会不会开始怀疑人生？果然，往后翻几页，作者自己也给出了忠告。

借用奇异博士的一句台词：“你TM居然把警告写在咒语的下一页！”

简而言之，防御式编程就是以怀疑的态度审视所有输入。但这和我们最初讨论的主题略有不同：我们面对的是“已有明确约定，但返回了约定之外内容”的情况。

契约式编程

讨论正酣，天空突然飘来五个字——哦不对，是另一个概念：『契约式编程』。

这个听起来有点意思！简单来说，契约作用于双方，每一方都需要完成某些任务来促成契约，同时也必须履行一些义务作为前提。任何一方无视了应尽的义务，契约便宣告失败。

契约式编程要求对『前提条件』、『后继条件』和『不变量条件』进行严格检查。例如参数检查，一旦参数不符合约定，立即“撕毁契约”。如今许多新语言都支持这种特性，比如Swift的参数约束检查，就是一种类契约式编程的实践。

契约所约束的，是“确保程序正常运行的必要条件”。一旦契约被破坏，原因只有一个：程序出了Bug。例如，某个数据字段在处理时必须非空，那么谁来保证这一点？必须是调用方（或其他模块）。因此，一旦出现问题，责任方应是调用方，它必须确保调用时传入的参数符合约定。

这让人想起早期面向日本企业编程时的一些经历。日本人的做事风格以谨慎和细致闻名，在详细设计阶段，每个方法、函数的参数、返回值、类型乃至所有可能取值都已定义清楚。方法之间有明确的界限，如果你的方法因为传入参数不符合设计而报错，你完全可以理直气壮地找到调用方，要求其按设计调用。不得不说，这堪称契约式编程的最佳实践。日企普遍采用这种方式还有一个原因：严格区分责任，让每个人都不必为了迁就他人的错误而进行“艰难的编码”。每个人只需按契约处理好自己的事，让破坏契约的人承担责任。

再引申一下，这和现在的『面向接口编程』也非常类似。两个模块之间定义好调用和处理的接口，具体实现对方无需关心，只要按照协议开发即可。但光有接口还不够，还需要契约来进一步约束参数和返回值。

无独有偶，《代码大全》中也提到了『进攻式编程』，其精神与契约式编程有异曲同工之妙。

乌托邦

好了，梦该醒了，让阳光照进现实。以上两种编程方式都非常理想化，但在大多数公司里，无论是推行防御式还是契约式，都面临实际困难。例如前端与后端的接口对接、不同部门同事的协作，按契约式编程，可能没人理会你的契约；按防御式编程，代码又容易变得惨不忍睹，且防不胜防。

那么到底该怎么办？一个可行的思路是：如果能在公司层面推广契约式编程，首先能提升开发效率，让每个人对自己写的代码负责，在开发者之间建立坚实的信任关系，同时减少不必要的沟通成本。但与此同时，必要的防御式编程也不能少，这是保证程序健壮与稳定的底线。

怎么说呢，这或许体现了千百年来一脉相承的智慧——『中庸之道』。契约还是防御？视具体情况而定。这终究是一门平衡的艺术。

警告

最后，建议各位以防御式心态阅读本文。毕竟每个人都会犯错，欢迎留言交流。

此文一出，很可能引发双方“混战”。红与黑，天灾还是近卫，联盟还是部落——Choose your side.