前言
前段时间呢,需要和xx公司进行对接。由于手上活比较多没忙不过来,领导就先帮我把接口调试完成了,并写好了相关的demo。然后我根据demo把代码整合进业务系统,并重写了相关代码。后来领导看了我写的代码,发现和他写的的demo不太一样,然后就问我为什么要重写?在一番争论后,领导对我说了句:你到底懂不懂抽象啊,你动了别人的代码边界。
事情的经过
领导:诶,你这个代码咋和我写的demo不太一样呢?
我:我看demo里面的代码有些地方,当返回错误信息的时候抛出了异常。但是实际情况是不能抛出异常,我就给他改写了。
领导:在使用的时候try catch
住处理一下不就好了。
我:这个确实可以,但是没必要这样做。多套一层 try catch
这样不是多此一举了吗。
领导:不是时间很赶吗,那在原有的基础上加一层 try catch
不是更快吗。
我:说是这样说,但是重写一下那部分又不耗多少时间,耗时间的是调整业务相关的逻辑代码。
领导:就这个原因吗,还有其他的吗?
我:这个只是一部分,还有有些写法看起来太臃肿了,可以用属性拷贝和类转换替换掉。这样代码看起来就比较精简了。
领导:减少了代码行数,就是你认为的精简嘛?
我:是的。
我:对了还有一个是,这个系统用的框架比较老。不支持枚举映射,所以我把一些参数类型变成String了。
领导:那你可以手动映射呀。
我:那我还不如用String接收,在使用的地方再用枚举。
领导:在我看来,你的改代码的理由,在我看来都不是理由。
我:为啥?
领导:在我看来你因为看那些写法不爽就把它给改了,可以这样理解吧。
我:占一部分原因吧。
领导:那你在用Spring的时候,发现有些代码让你看起来不爽,你会改它嘛?
我:不会。
领导:为啥呢?
我:因为改不了,没得权限。
领导:想改还是可以改的,去github上把代码拉下来,改了重新打包。
我:那这个也太麻烦了。
领导:那我是不是认为你因为麻烦或者说没有权限,所以你才不会改。
我:是的
领导:这样说的话,如果我把他弄成一个jar,让你用你是不是就改不了。
我:是这样的。
我:虽然是重写了,但是跟直接把代码拷贝过来是一样的,并没有增加系统的复杂度。
领导:你到底懂不懂抽象啊,你动了别人的代码边界。
我:我咋就不懂抽象了?
领导:这样和你说吧。
领导:原本呢,接口对接那部分是我写的,你只需要负责使用就好了。如果接口发生变更,我可以直接处理,你并不需要关心接口对接的逻辑。
我:是这样的。但你的代码并没有写在业务系统里啊。
领导:你直接拷贝过去就好了,这个和提供一个Jar有啥区别,而且代码我都测试过了,可以直接使用。
我: 是这样的。
领导:当接口发生改变的时候,我更改完,你直接把代码拷贝过去就好了。
我:额。。。。
领导:但是现在你把代码重写了,就没有那一层抽象了,也就只能你自己维护了。
我:这个本来就是我维护的呀。
我:但是系统的抽象程度还是没变呀。
领导:是,整个系统的抽象程度确实没变都是xx服务。但是我现在和你说的是这个项目的,不是整个系统的。
领导:回到之前那个问题。
我:嗯嗯
领导:这样和你说吧。当你在看代码的时候,觉得别人的代码写的可能不够规范,或者说不符合你的规范。因为你觉得不符合规范,这个只是你的主观判定,而不是一个客观的事实。在你看来不符合规范的代码,可能就是别人的规范。最好不要因为这个原因去更改别人的的代码。
我:好的
总结
不要去改变别的代码边界。当你更改了别人的代码,就意味着破坏了别人的代码边界。一旦边界被破坏,那就可能出现无法预估的风险。
结尾
说的通俗一点就是,不要瞎鸡儿改别人的代码。不管别人写的好不好,只要没bug就行,如果有bug也是别人改。有这个时间早点下班不好吗。
如果觉得对你有帮助,可以多多评论,多多点赞哦,也可以到我的主页看看,说不定有你喜欢的文章,也可以随手点个关注哦,谢谢。
我是不一样的科技宅,每天进步一点点,体验不一样的生活。我们下期见!