终于弄明白了防御式编程，却感到一丝心酸

这几天上网，经常看到一个名词：防御式编程。开始没在意，但看到次数多了，不禁感到好奇。一个编程常识，怎么这么多人在说。仔细一看，原来是旧词新解：

35岁以上的程序员，为了不被公司优化掉，故意将代码写的只有自己能看到的懂，别人想改都不知如何下手。

真的是很无奈，一个好好的词又被毁掉了。防御式编程的含义本意是宽进严出，也就是通常说的程序健壮性：在输入有错误的情况下，也能得到较好的结果。HTML 就是这样一个例子，即使包含错误，浏览器也能尽可能的展现出来。

我也能体会到这其中的心酸，不是被逼无奈，没人愿意这么干。但我不建议这种做法。

首先，这种做法其实起不了多大效果。作为一名接手过很多代码的老手来说，即使不是刻意为之，遗留代码就是传说中的“屎山”。补丁加补丁，维护起来提心吊胆，根本就不在乎你这多添的一坨屎。这可不是夸大其词。比如 Hacker News 上有一则讨论，「你见过的最大规模的烂代码是什么？」，有 Oracle 内部员工吐槽：

甲骨文数据库 12.2 版本，差不多有 2500 万行 C 代码。

这简直是难以想象的恐怖！在这个产品中，改动任何一行代码都会导致成千上万的现有测试失败。几代程序员在严峻的截止日期下工作，使代码充满了各种杂乱。

非常复杂的逻辑、内存管理、上下文切换等都是由成千上万的标志维系在一起。整个代码充满了神秘的宏，没有拿笔记本手动展开宏的相关部分，是无法理解的。理解一个宏的作用可能需要一到两天。

有时候，需要了解 20 个不同标志的值和效果，才能预测代码在不同情况下的表现。有时甚至需要了解上百个。我并不夸张。

这个产品之所以还能存活并运行，完全是因为数以百万计的测试！

这可是外国著名公司，尚且如此，国内更不用说。很多开发人员都有这种感受，接手别人的代码，恨不得上去重写一遍。

所以说，这种防御式编程，典型的损人不利己。代码写得再绕来绕去，别人顶多无视，基本上是哪里出问题改哪里。再说你写了一段难懂的代码，你保证过了一段时间能看懂？这不是也坑了自己吗？

其次，这种说法虽说是某鹅厂传出的，但我总觉得这是一个段子。大厂的代码审核还是挺严格的，特别是对于上线的产品，每一个改动都需要详细说明理由，否则过不了审。在这种情况下，你想防御式编程，早就死翘翘了。也只有在少数小公司，没有代码 review，也许可以过关。但还是有代码提交记录。万一哪一天主管心血来潮，查看一下代码提交记录，这点小心思，还是很容易看出。这种状况下，在公司还怎么混？

最后，人还是得走正道。这种歪门邪道走多了，容易入魔道。今天你做了个防御式编程，明天你可能觉得还是不保险，干脆植入个后门，这样杀伤力更大。殊不知，这样做妥妥的违法，是要进去的，这样的例子我身边就有。

虽然大环境不行，但这不是我们作恶的理由。