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