请大家关注我的公众号,“老胡聊Java”
这句话非常有道理,因为这句话不仅包含了技术,而且还包含了人情世故。
1 一个项目的代码动辄几千几万行,而且分布的位置也不同,比如有java代码python代码,甚至还可能有数据库SQL代码,你修改了其中一段,谁也不知道其它哪些地方调用了它。
而且哪怕你全局搜索了项目,也未必能确保其它项目,比如其它子模块或数据库SQL语句,一定没有调用它,所以你修改了,真可能会引发问题。
2 当下的代码大概率是经过多轮测试,即跑到现在是正常的。但如果你修改了不出问题还好,如果出了问题,别人一定第一时间会认为是你的责任,项目经理第一应对的措施,不是说让排查问题,而大概率是让你改回去。
3 而且你去修改这段代码,如果是远古代码,原作者已经离职,这还好说,如果原作者是你的同事,人家会怎么想?不少人会认为,你去干涉了他的工作,或者冒犯了他的工作领域。
当然如果你改得有道理,或者没有引入问题,那还好说。但如果引出问题,或者问题出在你改动代码所在的类甚至是模块,那么出问题,别人真会说,本来是好的,但xx改动后出了问题。这样哪怕原来代码就有问题,你一时半会还很难说清楚。
4 站在项目经理的角度来考虑,第一要义是能按时正常地把项目发布出去。这个过程中,哪怕有隐藏bug,但如果客户或测试没测出来,只要别让人说“发现了但不修改”,项目经理是没责任的。
具体来说,项目发布前会有套回归测试的流程,如果有隐藏bug,但回归测试没发现,出了问题,真可能是测试和开发一起分担。但如果发布前,有开发人员在功能正确的前提下,依然用所谓“代码重构”的理念去修改,那就属于多事。项目经理一般不会表扬,虽然不会批评,但至少会腹诽。
5 和项目发布相关的所有人,其主观上一定是期待项目能正确发布,或者是,至少别在我手上出问题。很多话只能说,比如期望代码高质量,或者代码架构好,这些话一定只是说给客户和领导听。
但如果真去照有些标准去做了,比如真去没事重构代码了, 大概率会增大别人的工作量。比如项目经理会因此担责,测试人员得多测,而且真出了问题,所有人都会承担连带责任。
当然如果修改的时候,你说你的出发点是为了代码质量或架构,那别人还真没法说,但这种事情尽量别多做。
6 当然开发项目时,确实得确保代码的质量,但这第一得有人牵头做,第二得有明确的标准。比如某项目在开发时,由项目经理或测试leader负责质量,是用某扫描工具,发现有问题,比如重复代码过多或命名不规范,会让人修改。
不过如果有人私下发起,这不免有越俎代庖之嫌,或者重构代码时不按规范随意修改,这就属于不可控的风险。
7 比如在面试中,有程序员说,我在做项目时,当看到现有代码有架构等方面的问题,我会顺手重构。那么这其实并不是加分项。或者是,比如有人说,自己经常会重构项目代码,那么有经验的面试官,大概率会质疑其项目的真实性。毕竟很多项目开发时间很紧,没有专门的时间来重构代码。