背景
防御式编程有两重解释，一种是比较正式的，另一种是梗。
正式的防御式编程
目标：程序的健壮性
执行方式：在错误处理时，尽可能考虑全面，不依赖外部输入。
在编码过程中针对不同场景的错误处理应该尽可能完善，
比如，在前后端分离架构中，后端接口在做字段合法校验时，应该默认前端没有做合法性校验，从而不依赖前端的实现，最终实现整个功能的健壮。
可能存在的问题
如果完全照搬理论，可能会导致整个业务代码结构臃肿，同时，也会增加不必要的运行时性能损失，
而我们维护业务代码的首要目标，就是尽可能地保持简洁，方便后续维护。
因此，哪些代码块应该做错误处理，哪些应该默认正常，只能凭经验做决定。
我的建议是，通过离业务代码最近的单元测试来弥补这部分逻辑验证；
同时在单元基础的基础上再补充适当的集成性测试去进一步降低风险。
这样的话整段代码在简洁性和稳定性之间有了一个更合理的平衡。
玩笑的梗
有人为了防止项目结束后被辞退，在开发阶段故意写一些晦涩难懂的代码，使别人难以接手，间接提高自身在团队中重要性。
也许这种情况曾出现过，但平时谈论到这个话题时，更多是开玩笑。