交易|之前的开发团队写了一堆烂代码，能跑起来，我要不要动还是重构？交易

文章图片

文章图片

曾担任搜狐高级开发的老张最近面试上了一家新公司，金榜题名时，本来高高兴兴的，毕竟每一次跳槽都意味着薪资的上涨。

可是这个老张怎么也高兴不起来，原因要从老张入职那天说起。

当天办完离职手续，公司的一哥们就来给他交接项目，他说这个项目之前已经有七个人在维护了，所以项目看起来比较凌乱，然后这哥们重点讲了项目中的核心功能，以及各个模块的依赖关系。然后交给老张一大堆接口文档和数据库文档。第二天就不来了。

结果第二天老张打开项目，代码垃圾的不能再垃圾了，一个bean定义set/get方法有几万行，一个类有500个成员变量，继承根本不用， lombok也不用，并且代码到处飞magic Number ，一会“bean.getParamType() == 2“ ，一会if (errCode == 5) ” ，竟然不写成一个枚举类，并且代码中没有任何单元测试，而且还没有任何设计模式。

一个后台项目里几千个controller ，一个service方法上万行都弱爆了，你见过整个项目就一个controller类，类里就一个post方法，整个项目通过不同传参type来区分不同的接口，老张看了后，整个人都崩溃了，这也太垃圾了。

还能怎么办，重构呗。

但是自己的时间不多，还要完成公司交的其它需求，只能抽时间或者利用休息日重构。
可是悲伤往往与善良伴随，本身自己重构是好事，却成了悲剧。
六个月后，老张信心满满的把重构好的代码放在了生产环境，当天，老张还特意仔细的测了测，确保没问题，凌晨3点多才回家。

正休息的老张，突然公司总经理打来电话，说线上给第三方支付的交易有的多支付了一笔，刚躺下的老张晚饭都没来的及吃，就跑去了公司。
排查了一下，支付交易原来走的是单线程，这样会导致支付交易变慢，老张好心改成了多线程，去掉了线程锁，可是这不改不要紧，支付系统的重试机制，让上一次的结果还没返回，重试的这一次查询数据库未支付，又重新支付了一笔。

让人惊喜的是，公司追回了欠款，但是公司规定，写一个bug按照严重程度需要罚款，当时清晰的记得老张被罚了4000元，并且当月的绩效也没有了，真是赔了夫人又折兵。
程序跑起来就不要动，一点也不杞人忧天。
编程届的第一法则：如果您的代码已经跑起来了，请不要尝试修改它了，一代代的老人给我们的警示，你看看这么多年微软敢动那个控制面板么，不要相信高度不够什么的话。

【交易|之前的开发团队写了一堆烂代码，能跑起来，我要不要动还是重构？】总之，在外界环境不干扰的情况下，软件会持续运行下去，已经烧高香了，怎么可能还想着动它？