以下内容人物均为杜撰,如有巧合,纯属雷同。
从前有个程序员,叫阿星,在小公司工作了2,3年,经过了好多轮技术面试的奋战,终于成功加入了Banana公司,是一个很有名的技术大厂。阿星加入的部门是一个负责公司支付业务的中台团队。
阿星在Banana公司的前几个月,主要做一些零散的小需求,一直没机会上手一些核心系统的开发,不过偶尔也会翻阅一些老系统,有不懂或者觉得和自己想法不一样的地方会咨询老同事。
有些时候,老同事都会有句口头禅,这是历史代码的问题,这一块改了影响不知道有哪些,会增加回归成本,这期先这样往上加吧,后面再看看。
每次听到这样的结论,阿星因为是新人,也会赞同老同事的看法,认为这样的考虑是合理的。
但阿星内心总隐隐感觉不对…
因为在入职这段时间表现不错,领导走到阿星背后,拍了拍阿星的肩膀说:“阿星,最近我们要对接一个新的支付公司,叫好就付,你找老同事了解下之间是怎么对接其他支付公司的,你来做一下这件事情。”
阿星内心OS:“终于可以参加核心流程的开发了,太棒了”
阿星找老同事了解了下,对接一个新的支付厂商,需要增加一个对应的开通支付的功能,对接支付的功能以及处理开通信息回调的功能。
阿星拉取了主要用来对接支付的的系统,主要是通过定义了一个标准接口给上游系统,内部通过上游分发的展示Id,将展示Id转换成该系统可识别的厂商Id,进入各自的主流程。
阿星要来了新的厂商的接口文档,将上面的三个功能都增加了一个新的分支加以实现,并添加了上游展示Id和好就付厂商之间的转换代码。
进入测试阶段,阿星发现,直接调支付功能是通的,但是开通功能一直不通,仔细查阅了代码发现,原来开通和支付这里各自维护了一套展示Id和厂商之间的转换关系。
阿星为了避免部署上代码后,还是测不通,仔细查阅了整个系统,发现这样的转换关系,在系统内维护了7个地方。
阿星看了看老同事的实现,都是用到一个新功能时,将原有的转换代码直接拿了过来,增加了一个新的分支。
阿星觉得这样的转换逻辑应该维护在一个统一的地方,否则之后新增或者修改一个厂商,每次改动一个厂商需要修改这7个地方,而且随着功能的新增,可能还会增加。
阿星询问了之前的老同事,老同事说 他实现的时候也是看之前的代码就是这么写的,确实也觉得不太合理,但历史都是这么写的,自己就继续往后加了。
阿星陷入了犹豫,自己应该是优化这块功能,还是继续延续老的用法,等到实在改不动了再修复。
你会怎么做呢?想一想,可以留言回答~
阿星想了想,如果我也继续这么做的话,那么下一个人可能也会继续这么做,那么这段不合理的处理方式就会一直延续下去,永远没有结束的那天,也就无法成为一份好的代码,这可是我梦寐以求加入的公司啊~
可是改这么多地方,会不会影响很多,阿星主动找了资深的同事,说明了自己的想法,同事也认可了自己的做法,之前开了一道口子,现在越来越大了,是应该修复了。
来吧,看我的天马流星拳!(抱歉,阿星有一些中二)
阿星将所有负责转换的逻辑,都抽取了出来,统一到了一个地方,增加了注释,并将原来各处的调用,都收拢到了一处,虽然为此阿星加班测了好多不是他这个需求的功能,但阿星内心是满足的,自己做了一件正确的事。
在阿星修复了这个口子之后,又紧接着对接了好几个新的厂商,大家再也不需要修改7个地方了,阿星有种深藏功与名的感觉。
之前阿星在修复的问题的时候,在想,为什么之前大家都看到了这个问题,但是没人在第一时间发现这个问题后修复呢?
直到有一天,阿星了解到了这个理论 - 破窗效应。
破窗效应(英语:Broken windows theory)是犯罪学的一个理论,该理论由詹姆士·威尔逊(James Q. Wilson)及乔治·凯林(George L. Kelling)提出,并刊于《The Atlantic Monthly》1982年3月版的一篇题为《Broken Windows》的文章。
此理论认为环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉。一幢有少许破窗的建筑为例,如果那些窗不被修理好,可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内,如果发现无人居住,也许就在那里定居或者纵火。一面墙,如果出现一些涂鸦没有被清洗掉,很快的,墙上就布满了乱七八糟、不堪入目的东西;一条人行道有些许纸屑,不久后就会有更多垃圾,最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象,就是犯罪心理学中的破窗效应。
阿星看完之后明白了,在软件开发中其实也存在着破窗效应,当一处不合理的开发出现后,没有在第一时间修完这个破碎的窗户,接下来的人就可能会在修和不修之间动摇,有概率让这个窗户变的更大,让这个窗户变的更难修复。
阿星最后意识到,无论是小厂还是大厂,代码是靠大家一起维护的,只有大家都有修窗户的意识,才会让系统变的越来越好,否则只会将问题都甩在历史问题上,可是历史问题又是谁造成的呢?