在项目维护的过程中，由于工程师水平的参差不齐，很多需求时间紧、任务重，或又因前几任工程师离职没做好交接，导致了大量的可读性差、效率低下的代码，这时候，在职的工程师最想做的恐怕就是重构代码，将那些垃圾代码舍弃，按照自己良好的设计重新实现一遍。
在工程师看来，重构之后有非常多的好处：
- 代码更简洁，可读性、可维护性更强
- 实现新的需求效率更高
- 新人的学习成本更低
重构之后丢弃了过往的累赘，往往也会丢弃了过往的经验。尽管过去的代码十分丑陋，但它们确确实实可以正常地运转。如果要重构，能保证新的代码不会像过去团队的代码一样，慢慢变丑陋吗？依然会面临同样的风险，而且，过去团队已经付出的时间成本，还要再次付出一遍。
我所负责的项目就经历过这样一次重构，带来好处的同时也带来了很多伤害，主要有以下几点：
1. 用户很长时间看不到产品的变化，容易对产品失去信心
按照原本的开发计划，团队每周会响应客户反馈的 2 个改进意见，修正 4+ 个 bug，约两个月推出一个重点功能...用户每周都能感受到产品在改进，这会让用户更加喜爱你的产品，重构意味着舍弃了正常进度的产品更新，而需要花大量的时间来重新组织代码，而这所有改进，用户完全感知不到，一旦在某些功能上落后于竞争对手，可能就直接导致用户流失。
2. 以前遇到的坑基本会再踩一遍
工程师往往会低估重构的难度和所要消耗的时间，以前遇到的坑基本会再踩一遍。比如，在过去的版本中，导出的数据是带有公司 logo 和精美样式的 EXCEL 文件，重构时就没有考虑到这一点，结果又花了大量的时间去调整导出文件的样式。
为实现某个特殊需求，旧版写了很多丑陋的代码，在重构的时候，依然没有想到优雅的办法，但是用户已经严重依赖这个功能，又必须实现，后来重构的版本依然通过非常别扭的方案实现这个需求。
3. 技术上没有包袱了，但产品上的包袱更重
如果重构涉及到前端用户看到的部分，则面临的压力会更大。在过去的版本中，用户体验被打磨的非常细致，甚至很多你想不到的地方都被用户熟练掌握，一旦交互上有稍微大的改动，就会影响到他们的正常使用。
重构的版本还很难使用敏捷的方式快速迭代，一旦推出了新版的最小可行化版本，用户会吐槽比旧版差远了，为啥要用这个，如果要测试成熟再推出，用户等待的时间则会更加漫长。
4. 竞争对手利用这段时间可能已经走很远了
在重构的这段时间，你的竞争对手在马不停蹄的开发新的功能，拓展新的客户，而自己的产品对于客户来说却停滞不前。在重构之前，一定不能只从工程角度考虑问题，还要想想公司的生意。
如果必须要重构，如何做？
首先，在日常的项目管理中，为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，避免“需要停下来重写代码”的情形发生。如果现有代码已难以维护，这里给出一点建议供参考:
- 针对重构和日常需求制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是多数团队没有重构的实际经验，估计往往会过于乐观。这时必须仔细检查每处细节，确保计划切实可行。
- 把重构目标拆解，实现递增修改，同时要花精力保持产品迭代，让用户感受到产品的改进，哪怕会因此把3个月的工作时间延长至半年。重写代码时，保证让用户看到功能的改进——即使会占用少则25%，多则50%的开发资源——对保持产品的市场占有率至关重要。
- 由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，确保产品定义的正确性。
