前言
前段时间呢，须要和 xx 公司进行对接。因为手上活比拟多没忙不过来，领导就先帮我把接口调试实现了，并写好了相干的 demo。而后我依据 demo 把代码整合进业务零碎，并重写了相干代码。起初领导看了我写的代码，发现和他写的的 demo 不太一样，而后就问我为什么要重写？在一番争执后，领导对我说了句：你到底懂不懂形象啊，你动了他人的代码边界。
事件的通过
领导：诶，你这个代码咋和我写的 demo 不太一样呢?
我：我看 demo 外面的代码有些中央，当返回错误信息的时候抛出了异样。然而理论状况是不能抛出异样，我就给他改写了。
领导 ：在应用的时候try catch 住解决一下不就好了。
我 ：这个的确能够，然而没必要这样做。多套一层 try catch 这样不是多此一举了吗。
领导 ：不是工夫很赶吗，那在原有的根底上加一层 try catch 不是更快吗。
我：说是这样说，然而重写一下那局部又不耗多少工夫，耗时间的是调整业务相干的逻辑代码。
领导：就这个起因吗，还有其余的吗？
我：这个只是一部分，还有有些写法看起来太臃肿了，能够用属性拷贝和类转换替换掉。这样代码看起来就比拟精简了。
领导：缩小了代码行数，就是你认为的精简嘛？
我：是的。
我：对了还有一个是，这个零碎用的框架比拟老。不反对枚举映射，所以我把一些参数类型变成 String 了。
领导：那你能够手动映射呀。
我：那我还不如用 String 接管，在应用的中央再用枚举。
领导：在我看来，你的改代码的理由，在我看来都不是理由。
我：为啥？
领导：在我看来你因为看那些写法不爽就把它给改了，能够这样了解吧。
我：占一部分起因吧。
领导：那你在用 Spring 的时候，发现有些代码让你看起来不爽，你会改它嘛？
我：不会。
领导：为啥呢？
我：因为改不了，没得权限。
领导：想改还是能够改的，去 github 上把代码拉下来，改了从新打包。
我：那这个也太麻烦了。
领导：那我是不是认为你因为麻烦或者说没有权限, 所以你才不会改。
我：是的
领导：这样说的话，如果我把他弄成一个 jar，让你用你是不是就改不了。
我：是这样的。
我：尽管是重写了，然而跟间接把代码拷贝过去是一样的，并没有减少零碎的复杂度。
领导：你到底懂不懂形象啊，你动了他人的代码边界。
我：我咋就不懂形象了？
领导：这样和你说吧。
领导：本来呢，接口对接那局部是我写的，你只须要负责应用就好了。如果接口产生变更，我能够间接解决，你并不需要关怀接口对接的逻辑。
我：是这样的。但你的代码并没有写在业务零碎里啊。
领导：你间接拷贝过来就好了，这个和提供一个 Jar 有啥区别，而且代码我都测试过了，能够间接应用。
我：是这样的。
领导：当接口产生扭转的时候，我更改完，你间接把代码拷贝过来就好了。
我：额。。。。
领导：然而当初你把代码重写了，就没有那一层形象了，也就只能你本人保护了。
我：这个原本就是我保护的呀。
我：然而零碎的形象水平还是没变呀。
领导：是，整个零碎的形象水平的确没变都是 xx 服务。然而我当初和你说的是这个我的项目的，不是整个零碎的。
领导：回到之前那个问题。
我：嗯嗯
领导：这样和你说吧。当你在看代码的时候，感觉他人的代码写的可能不够标准，或者说不合乎你的标准。因为你感觉不符合规范，这个只是你的主观断定，而不是一个主观的事实。在你看来不符合规范的代码，可能就是他人的标准。最好不要因为这个起因去更改他人的的代码。
我：好的
总结
不要去扭转别的代码边界。当你更改了他人的代码，就意味着毁坏了他人的代码边界。一旦边界被毁坏，那就可能呈现无奈预估的危险。
结尾
说的艰深一点就是，不要瞎鸡儿改他人的代码。不论他人写的好不好，只有没 bug 就行，如果有 bug 也是他人改。有这个工夫早点上班不好吗。
如果感觉对你有帮忙，能够多多评论，多多点赞哦，也能够到我的主页看看，说不定有你喜爱的文章，也能够顺手点个关注哦，谢谢。
我是不一样的科技宅，每天提高一点点，体验不一样的生存。咱们下期见！