自己的代码被别人改动这事，应该不少人遇到过，作为当事人之一，你介意吗？
我也遇到过，甚至在改动前基于修改人本身的一些情况，我会变得谨慎起来，甚至有些抵触。理由很简单：一个能力比你差得人要改你的代码，你不紧张下。即使他的修改能实现需求，等到你看到修改的代码可能是这样的：
逻辑有些混乱，可以简化下，为什么要搞这么复杂，不是有现成的SDK可以用吗？
很多无用的语句，无效的引用依然留在源代码中，即使编辑器中已经有黄色标记警告也无动于衷；
调试输出的语句直接用print而不用日志组件，事后又没有删除、注释掉；
注释和代码不对应，复制粘贴惹的祸；
命名不规范，拼音英文混合，自己搞的缩写；
文件目录划分混乱；
单个文件代码过多，很多不相干的功能塞在一个类中；
修改了已有接口的内部逻辑，却不知道这个接口还有其他地方在调用。导致他自己的功能没问题了。已有的功能出问题了。算是挖了坑；
这些基本都遇到过，当然还有其他很多因修改引起的问题。遇到了这些，你还能淡定吗？
如果你已经不再参与这些项目，不用写这些代码，自然无所谓。
当你还要参与项目开发，还是主要负责人呢？估计你会发飙、抓狂。开始也许还有耐心提出些建议，慢慢的同样的错误一而再，再而三的犯，都不愿意再交代任务让其完成。或者在他提交了代码后，还要看下实际运行效果，看下代码。生怕挖了什么坑。因为一旦出了问题，领导首先需要的是能快速解决问题的人。而这时也就是你来顶上。所以有时候我宁愿任务往后压下，自己来做，也不愿意别人接手。不是觉得自己多牛，也不是觉得自己有多好的精力，想图表现。而是很多时候，别人做的时候你要仔细和他交代，中途还要协助下，最后收不了场了，还得自己去救场。后期再开发，本应该是由原来的开发者做，为了赶时间，领导觉得你能力强，效率高，让你来接着开发。有些开发员属于过路，开发一段时间就走了。还有就是一直做开发，维护项目的，一般也是个小负责人。代码没有控制好，最后苦逼的就是他了，他是最后兜底的人。
这就涉及到我改别人的代码了。同样我也不愿意改人家的代码，原因也简单：要改他的代码，就先要看他的代码，理解他的思维逻辑，处理过程。对于那些注释少，甚至没有或者干脆还是牛头不对马嘴，代码命名还是拼音加缩写的。就很难看明白了。再遇到使用的组件过时，架构不合理。你还有改下去的动力吗。宁愿另起炉灶都比这快。只有不得以的情况下，才去使用，修改前任的代码。
在这种情况下，修改前我会把接口名字故意改动下，IDE一般就会有错误提示，哪些地方引用到该接口；或者新建一个方法，甚至一个文件，利用装饰模式利用原接口做功能增强或调整，这样既不改动原接口，也能实现自己的需求。
有些可能还会引入新的组件，sdk来实现自己的需求。因为每个人都有自己的技术栈，别人使用的东西对自己来说太陌生还得花时间去学习，或者不习惯用已有的组件，自己有更好的选择。但这也会给整个项目代码带来另一问题，随着时间的增长，参与人员的增加，都按自己的技术栈来完成自己任务，最后项目中就充斥着各种组件，甚至同类组件出现各版本。这对后期的项目维护是很大的危害。
可能有人会说都是从新人过来的，都是从这样的过程走过来的。问题是一些基本原则不应该忘记或完全不知。改别人的东西，可以先找原作者了解下情况；利用些技术手段规避修改带来的问题；重要的是同样的错误，不要一再犯。不要一上来就是一通猛改，自己的功能能跑通就可以。不管对原有的功能有没有影响，会不会给别人挖坑。不能走自己的路挖坑给别人，让别人填坑。这也不是什么多高深技术问题、经验问题，这首先就是做事的一个认知问题。不是所有的知识都是从教训中获取的。