海量老代码是否要重构？如果要重构，需要注意什么？

      今天部门讨论海量老代码是否重构的问题？关于是否重构，还是要从源头进行分析，首先作为一家商业公司，发布产品的唯一目的还是满足客户需求赚取利润；那么对于海量的老代码，我认为考核的唯一一点就是投入产出比如何，是否能给产品带来实实在在的收益？如果可以，重构就是好的选择，当然重构海量老代码，短期是需要加大投入，短期上的业绩难于有所表现，所以考核还是要拉长周期去衡量。根据本人参与研发多产品的经验和数据，建议从这三个维度进行分析权衡：产品所处的生命周期，产品当前质量表现，需求情况，可以参考下表选择。

生命周期	质量	需求	重构选择建议
早期	未知	一般比较多	重构
中期	好	少	不重构/有选择的重构
中期	差	不定（多/少）	控制节奏的重构
尾声	趋于稳定	一般较少	不重构
尾声	多	一般较少	重构（开发替代全新产品）

1. 产品处于生命周期早期，还是要坚决重构，这对后期维护，产品整体竞争力都有好处，收益往往大于投入。
2. 产品处于生命周期中期，质量问题少，需求少，这时不进行重构或者有选择的重构；
3. 产品处于生命周期中期，质量问题比较多，这时团队需要下决心聚焦短时间投入要把重构开展起来，但要注意控制节奏；
4. 如果产品已经是生命周期尾声，后续基本没有需求，产品质量也稳定，那么不再重构是好的选择；
5. 产品已经是生命周期尾声，质量问题还是比较多，重构，思考替代的全新产品。

已经决定重构时，如果产品已经是量产，重构不影响质量是底线，至少不能影响原有特性质量，这是树立产品口碑，和建立客户对产品质量信心的大事，是重中之重；其他还需要考虑如下三方面的事情：

1. 保证投入，下定决心聚焦投入；在主干上拉分支，团队短期能不接或者少接新的需求的开发任务；
2. 考虑升级前后兼容性；
3. 发布节奏控制，内部验证，少量发布，没有质量问题后逐步上量发布。