序

具体想写这个话题的原因是之前在写一个新的业务需求，因为笔者是刚刚接触这个业务，所以就需要从头到尾的梳理一次业务逻辑，刚好需要新加的功能在前面的流程中有很强的业务逻辑保证，所以笔者就减少了一些不必要的数据校验，直接使用了，但我的导师进行代码复读的时候却告诉我，不要这么干，一定要进行校验。

真的需要防御性编程吗

笔者就事论事的来说这件事情，稍微总结一下具体的业务逻辑，在前面的逻辑校验中，业务逻辑会对数据进行存储，并且保证了这个数据一定会存储进去，后续也拿取过一次，也能正常拿取到这个数据，中间没有任何对该数据进行修改的操作，然后笔者直接拿取到这个数据进行操作。

也就是这里，导师让我进行一个验空的操作，而他给出的理由就是，如果后续有人改动前方代码并且没有看见你的逻辑呢。

笔者人生地不熟的，没办法加上了验空的判断，其实在个人看来，本身自己的考虑是，既然前方保证了我这段逻辑一定是没有问题的，我为什么要多加上那些无用的防御性代码呢，如果每个人都这么写，每一次迭代都要加上防御性的逻辑书写，本来耦合性很强的一段代码逻辑就会变得零碎起来，有一种自己把自己从内部瓦解的感觉。

再讨论到导师给出的理由，如果一个人在后续迭代开发中，不能完整的看完和浏览完这么简单通俗的一个逻辑，我就可以合理怀疑公司招聘人的能力了，一个程序员的基本素养对代码怀有敬畏之心，任何的改动，尽量的明白他造成的结果是什么， 他会受什么影响，并将其根植于心。就像这段逻辑，如果完整的方法都看不完就开始改动代码逻辑，本身素养就很有问题，再谈论到代码本身来说，一个程序的代码频繁的对一个具有很高内聚的片段不停的做改动，这本身就很反常，这段代码就有被重新构建的可能。

其实说了这么多，笔者最终想表达的无非就是，代码编写的过程中，不要把你所写的系统所有的东西看成一个个小小的独立个体，在一个系统内是一个统一的整体，对于应该内聚的逻辑一定要保证逻辑的健壮性，所有的修改本身就应该建立在拓展的基础上，尤其是对于作者现在负责的一个四年左右的老项目。

结

作者还是比较喜欢遇到这些事情进行一些思考，不论是自己想了什么还是自己想不到或者想法错误的等等问题，希望能够共勉吧，言尽于此好好吃饭。