请大家关注我的公众号，“老胡聊Java”

这句话非常有道理，因为这句话不仅包含了技术，而且还包含了人情世故。

1 一个项目的代码动辄几千几万行，而且分布的位置也不同，比如有java代码python代码，甚至还可能有数据库SQL代码，你修改了其中一段，谁也不知道其它哪些地方调用了它。

而且哪怕你全局搜索了项目，也未必能确保其它项目，比如其它子模块或数据库SQL语句，一定没有调用它，所以你修改了，真可能会引发问题。

2 当下的代码大概率是经过多轮测试，即跑到现在是正常的。但如果你修改了不出问题还好，如果出了问题，别人一定第一时间会认为是你的责任，项目经理第一应对的措施，不是说让排查问题，而大概率是让你改回去。

3 而且你去修改这段代码，如果是远古代码，原作者已经离职，这还好说，如果原作者是你的同事，人家会怎么想？不少人会认为，你去干涉了他的工作，或者冒犯了他的工作领域。

当然如果你改得有道理，或者没有引入问题，那还好说。但如果引出问题，或者问题出在你改动代码所在的类甚至是模块，那么出问题，别人真会说，本来是好的，但xx改动后出了问题。这样哪怕原来代码就有问题，你一时半会还很难说清楚。

4 站在项目经理的角度来考虑，第一要义是能按时正常地把项目发布出去。这个过程中，哪怕有隐藏bug，但如果客户或测试没测出来，只要别让人说“发现了但不修改”，项目经理是没责任的。

具体来说，项目发布前会有套回归测试的流程，如果有隐藏bug，但回归测试没发现，出了问题，真可能是测试和开发一起分担。但如果发布前，有开发人员在功能正确的前提下，依然用所谓“代码重构”的理念去修改，那就属于多事。项目经理一般不会表扬，虽然不会批评，但至少会腹诽。

5 和项目发布相关的所有人，其主观上一定是期待项目能正确发布，或者是，至少别在我手上出问题。很多话只能说，比如期望代码高质量，或者代码架构好，这些话一定只是说给客户和领导听。

但如果真去照有些标准去做了，比如真去没事重构代码了， 大概率会增大别人的工作量。比如项目经理会因此担责，测试人员得多测，而且真出了问题，所有人都会承担连带责任。

当然如果修改的时候，你说你的出发点是为了代码质量或架构，那别人还真没法说，但这种事情尽量别多做。

6 当然开发项目时，确实得确保代码的质量，但这第一得有人牵头做，第二得有明确的标准。比如某项目在开发时，由项目经理或测试leader负责质量，是用某扫描工具，发现有问题，比如重复代码过多或命名不规范，会让人修改。

不过如果有人私下发起，这不免有越俎代庖之嫌，或者重构代码时不按规范随意修改，这就属于不可控的风险。

7 比如在面试中，有程序员说，我在做项目时，当看到现有代码有架构等方面的问题，我会顺手重构。那么这其实并不是加分项。或者是，比如有人说，自己经常会重构项目代码，那么有经验的面试官，大概率会质疑其项目的真实性。毕竟很多项目开发时间很紧，没有专门的时间来重构代码。