序
具体想写这个话题的原因是之前在写一个新的业务需求,因为笔者是刚刚接触这个业务,所以就需要从头到尾的梳理一次业务逻辑,刚好需要新加的功能在前面的流程中有很强的业务逻辑保证,所以笔者就减少了一些不必要的数据校验,直接使用了,但我的导师进行代码复读的时候却告诉我,不要这么干,一定要进行校验。
真的需要防御性编程吗
笔者就事论事的来说这件事情,稍微总结一下具体的业务逻辑,在前面的逻辑校验中,业务逻辑会对数据进行存储,并且保证了这个数据一定会存储进去,后续也拿取过一次,也能正常拿取到这个数据,中间没有任何对该数据进行修改的操作,然后笔者直接拿取到这个数据进行操作。
也就是这里,导师让我进行一个验空的操作,而他给出的理由就是,如果后续有人改动前方代码并且没有看见你的逻辑呢
。
笔者人生地不熟的,没办法加上了验空的判断,其实在个人看来,本身自己的考虑是,既然前方保证了我这段逻辑一定是没有问题的,我为什么要多加上那些无用的防御性代码呢,如果每个人都这么写,每一次迭代都要加上防御性的逻辑书写,本来耦合性很强的一段代码逻辑就会变得零碎起来,有一种自己把自己从内部瓦解的感觉。
再讨论到导师给出的理由,如果一个人在后续迭代开发中,不能完整的看完和浏览完这么简单通俗的一个逻辑,我就可以合理怀疑公司招聘人的能力了,一个程序员的基本素养对代码怀有敬畏之心,任何的改动,尽量的明白他造成的结果是什么, 他会受什么影响,并将其根植于心。就像这段逻辑,如果完整的方法都看不完就开始改动代码逻辑,本身素养就很有问题,再谈论到代码本身来说,一个程序的代码频繁的对一个具有很高内聚的片段不停的做改动,这本身就很反常,这段代码就有被重新构建的可能。
其实说了这么多,笔者最终想表达的无非就是,代码编写的过程中,不要把你所写的系统所有的东西看成一个个小小的独立个体,在一个系统内是一个统一的整体,对于应该内聚的逻辑一定要保证逻辑的健壮性,所有的修改本身就应该建立在拓展的基础上,尤其是对于作者现在负责的一个四年左右的老项目。
结
作者还是比较喜欢遇到这些事情进行一些思考,不论是自己想了什么还是自己想不到或者想法错误的等等问题,希望能够共勉吧,言尽于此好好吃饭。