背景
在实际开发过程中，我们经常遇到这样的场景：
- 后端报错了，手忙脚乱一顿排查，发现是前端传的参数为空，或者格式不对；
- 后端又报错了，传参没问题，根据日志流发现，是某“给力”队友，提供的方法返回为空了，或者返回了和预定义不同的结果；
- 后端“双”报错了，来不及掩饰内心的波动，“左右手一个快动作”又是一顿排查，发现又是那个“好”队友，提供的方法报错了，结果我作为调用者，也跟着报错了；
- 后端“叒”报错了，数据库记录爆炸了，出现了大量垃圾无用数据，排查一看，不知道是哪个“神”队友，大量高频的垃圾数据，调用我方接口
- ……
发生了上述场景，给人第一直观感受就是，是当前功能的后端出问题了；作为当事人的我们，明明不是直接的始作俑者，大概率被迫的委屈巴巴跟着背了一锅。那么有没有什么措施，我跟可以规避这种莫名其妙的背锅，“鸡智”的你，估计也想到了，就是和对方交互时，基于不信任的的防御性编程思想。
什么是防御性编程
防御性编程，基于我的理解，主要在于两点：不信任和防御。
不信任，就是不要总是乐观的认为外部传参都是没问题的、“好”队友提供的方法都是可靠的、第三方的Api都是稳定的、用户都不是“抽象”的，会按照正常的流程来操作等等。
防御，就是针对不信任，所引出来的意外情况，做出一些防御保护措施，来避免外部的不合理情况，对我们既有程序的不利影响。
为什么需要防御性编程
防御性编程，可以给我们带来以下好处：
- 方便规避责任，可以让人清楚知道，是谁的模块有问题，防止背锅；
- 保持系统稳定性，一些意外情况，我们做好校验，快速失败，防止错误越滚越大，从而保证系统稳定性；
- 方便错误排查，快速定位，和第一条类似，我们对不同来源的错误，给出不同的来源标识，发现错误后，可以快速根据标识，定位错误来源；
如何实现防御性编程
讲了这么多，那么有哪些具体措施呢？下面是我总结的一些措施，也欢迎大家补充。
- 入参校验；对方法的输入参数校验，字段是否为空、是否符合预期特定规则等，不符合则快速失败，不再往下走；
- 方法返回值判断；在调用方法时，拿到返回值后，经常需要进行后续操作，比如a.methodA()等，一旦返回值为空，则导致空指针；还有返回值为一个Map之类的操作，当我们取其中属性操作后续时，也记得进行判断；
- 对不信任的他人方法或第三方接口，通过try……catch捕获对应异常，对异常重新封装，标识来源后，再抛出去或做对应处理；重点是要，标识异常来源，好后续定位和定责；
- 使用安全、成熟的框架或工具类，经常有些同事，喜欢自己造轮子，或者在来源不明的网站，CV未经充分验证的代码，如果你也不假思索的随大流去用，很可能成为BUG的受害者；使用成熟的框架工具类，他们经过了大量的测试验证，能大大减少BUG出现的概率。
