维护过一个神奇的软件叫3ds Max，总代码量大概八千万行，其中据统计活代码三千万行（就是用户经常能使用到的代码）
不过具体到工作经常需要接触到的模块，也就几百万行的样子，有些很成熟的部分，比如图像读写之类的，基本上不用管它
然后整体大规模的重构基本不太可能，主要不是做不到，是因为没这个动力，搞的再牛逼也不一定能给公司带来更多的收入，而且我觉得没人有这个魄力和实力下决策也是个很关键的因素
其实各种小规模的重构也一直在做，不过吃力不讨好，如果不产出产品价值，用户也会觉得你没做啥，但是事实上你让这个软件的可维护性可能延长了五年
不重构能不能驾驭，当然临时驾驭一下是可以的，比如离发布时间比较近了，需要快速解决问题，我就一般会开启黑客模式，我就一个办法，先把关键路径（业务工作流）反复调试，调试到对这个路径上面的局部逻辑非常熟悉，然后开始Hack，把相关代码按照功能需求尝试着改一遍，可以就送测试，不行就回退，然后我会拿失败的数据再调试一遍，加深下对业务流程的理解，然后重新Hack一遍，这样每遍都会越写越好，最终总能搞定（除非证明这个功能需求就是错的，一般比较罕见）
不过大部分时候还是建议能重构就重构一下的，而且要持续重构，保持这软件的可维护性，不然自己以后回到同样的逻辑再来一次也会很痛苦，我为人人，人人为我嘛。当时团队是使用相互审核代码（peer review）的制度，反正太恶心的代码别人也不想维护，所以基本上review这关也过不了。
网友评论