一个空指针引发的代码走查思考

1、早上坐班车和高先生的探讨对我很有启发，今天在跟他聊这小确幸这件事情的目的和意义时，在用语言表达清楚的同时，也更能理清楚自己的内心对这件事情的期待和潜意识对这件事情的目的的认知，更加清晰。好像今年很多好的点子都是在班车上，一起交流的过程中产生，感恩小伙伴们，一起互为支撑，一起进步。

早上，在班车上跟高先生反馈，团队的升级测试希望可以借助他们OS+DB的自动化工具，一番需求探讨和澄清后，迅速达成共识，可以为团队节约了至少2人/天的人力，感恩高先生的鼎力支持。

感悟:跟高先生在沟通这个工作的过程中发生了一个很有趣的故事。作为用户，我首先给他表达了我想要做什么事情，达到一个什么效果。他收到我的需求后，根据现有的两个方案:永久性和一次性。永久性方案比较麻烦，而一次性方案则非常简单。于是，他向我提问，你的运用场景是一次性的？还是永久性的。我想了一下，其实一次性已经可以满足我们的需要。永久性只是我在不了解他的工作量的前提下拍脑袋想出来的一个方案。作为用户，我们需要的是尽可能细化和澄清需求运用场景，不要给对方提方案，方案需要由实现方来考虑。作为接收需求方，需要通过提问的方式，来引导用户发掘出用户背后真正的需求场景是什么。这个过程也是一个共创的过程，经过这样一个过程梳理出来的需求才能达到双赢的状态。

2、参加深度故障复盘，提到当我们在代码走查的时候，对于可能出现的空指针问题的关注。绝大多数时候，当我们遇到一个可能出现空指针的场景时，首先想到的是，如何做一个空指针保护，让代码在运行时不要抛出空指针异常。而其实，更重要的是，需要我们更进一步去搞清楚，可能出现空指针的场景是什么？这种场景下，从业务上来讲，应该如何去处理，而当我们面临一些比较复杂的存量烂代码时，我们往往说不清楚，什么样的场景会出现空指针，只是简单的做了一个甚至从业务上来讲是错误的容错保护，避免了空指针的发生，却导致了后面更加无法预知的更加复杂的问题的发生。这一类问题发生后，往往比起追查一个空指针的问题更加耗时和困难。

感悟:当我们遇到类似可能出现的空指针问题时，绝不能置之不理，任凭它作为隐患存在。更不能在没有搞清楚真正的业务场景和代码逻辑的情况下，草草去做一个所谓的空指针保护。尤其是针对已经比较复杂的存量代码。越是我们讲不清楚业务逻辑的代码，出问题的可能性反而越大。因此，我们应该把它作为一个信号，很好的利用这个信号去驱使我们搞清楚代码逻辑，业务场景。只有抱持这样一种态度，才能在日常工作中一点点逐渐把复杂代码理清楚，从而避免二次犯错，甚至三次犯错的可能。也是我们团队在代码层面可以深入下去的一个很好的切入点。

3、明天开始要参加姜信宝的两天CSM认证培训，期待这样一次充电之旅。

图片发自App