关于判空逻辑的思考

        工作五年来，经历过两款线上App的android端开发，并且都是大厂的产品。发现代码中有大量的判空逻辑，有的地方甚至已经到了令人发指的程度，几乎每个变量的使用都有判空逻辑。空指针异常号称“billion-dollar mistake”，在代码中随处可见；但是空指针异常也非常“容易解决”，如果只是解决空指针异常这个crash只需要一行判空代码就可以了，但是这种解决办法常常会导致显示的异常，例如：该有的信息没有显示出来、展示一个空页面、一个“网络错误请重试”的tips等。

线上app代码满是判空的背景

        每个商业产品都有一个crash统计和crash指标，而且每个领导都比较关心crash率，crash率过高整个开发团队就会承受很大的压力。在常见的crash中空指针异常又是非常容易解决的，所以在每个团队中几乎都不允许有空指针异常的存在，所以在开发中就加入了大量的判空逻辑，甚至有的几乎每个变量都判空，这样子就降低了crash率。一句话，crash指标逼的代码中到处是判空逻辑。

大量判空带来的问题

        首先就是代码不美观；其次也会牺牲一定的效率；更重要的是还有一个深层次的影响，大量的判空逻辑掩盖了一下代码设计的问题，在代码中一些不该为null的地方但是出现了null，说明代码的设计或通信有问题，但是有判空逻辑的存在开发者并不能及时发现这些问题。这样的代码上线后，可能就会导致用户的展示不符合逻辑；我们用牺牲用户信息展示有效性的方式降低了app的crash率。但是大多数app没有信息展示有效性这样的上报以及指标，所以开发者也很难发现问题，直至用户反馈才知道有问题。

判空逻辑使用的思考

1. 在代码与外部交互的地方必须使用判空逻辑，我们不能完全信任外部的数据。例如网络请求返回、第三方sdk接口返回、rpc调用等。
2. 在自己的代码内，对于逻辑上有可能为null的地方也必须使用判空逻辑，例如调用方法的返回值可能为null、sdk的回调某些可能为null的参数等。
3. 在自己的代码内，对于逻辑上明确不为null的地方尽量不要加判空逻辑，如果出现空指针应该去检查代码的设计。这些问题如果在测试阶段发现我们就可以及时解决；根据经验这些问题很难在测试阶段发现，但是通过灰度上线的方法，我们一般可以在灰度阶段发现这些问题并解决。如果在这些地方非要使用判决逻辑，也不要只简单的使用判空逻辑，判空逻辑应该与为空后的日志上报一起使用，这样我们能及时感知到代码设计的异常，为用户提供更好的信息服务。

 

Ref:

1.https://www.novatec-gmbh.de/en/blog/java-null-checks-everywhere-code-boundary-issues/