实现的妥协
记得刚开始工作那会，也正好是项目刚起步不久，我总是觉得公司原有的代码脏乱差，架构混乱，完全不符合我们在书上看到的标准。一直有把项目代码重构一番的念头。
工作几年后开始逐渐明白了一个道理，写代码不是造艺术品。代码的本质是功能的实现，在bug可控，能满足用户需求的前提下，其实并不需要那么完美。
打造完美的代码是需要成本的，在项目前期，人少活多，一个人顶三个人用，怎么也写不出花样来。这个阶段主要的目标就是尽快实现功能，抢占市场。那在设计和实现上必然会有妥协。
该不该重构
当你想重构现有代码的时候，需要问自己三个问题
- 重构的目的是什么？
为了换新框架增长技能还是对项目真的有益 - 现有的架构是否严重的制约了后续功能的开发和性能支撑？
如果是，那重构就非常有必要。在项目进行到某一阶段的时候，由于产品的策略调整，会带动功能在原有的基础上有较大改动。如果现有架构无法满足新策略，那么就到了必须要重构的时候。但前提是重构后的代码结构确实要优于现有的，所以重构前要做充分的评审。 - 是否有时间，有人力去重构？
即使满足上面的第一条件，但是项目上根本就不给足够的时间和人员去做这个事情，那也是无法完成的。从新架构的设计到评审，需要花费很多的时间。在重构的过程中，还得将原有的功能保质的迁移过来，又得花费很多的时间。后面还得加上回归测试的时间等等。这些成本的消耗，老板是否买单呢？
重构是一个比较重大的决定，牵扯到项目的方方面面。不是可以由技术人员单方面去决定是否能重构的。当然，如果真的很闲，重构不失为一个充实工作，提升技术的好方式。
如何实施重构
决定重构后，如何实施？
从我个人的实践经验来看，代码重构需要提前规划和布局，才能优雅的进行。项目技术负责人需要尽量提前预知在未来什么节点下，当前的架构无法满足业务，并提前协调资源开始规划重构。整个过程可以有以下两种模式：
- 整体重构，一气呵成。将团队分成AB组，A组继续在当前分支开发，满足业务发版本的需求。B组负责在新分支上在新架构的基础上开发并迁移旧功能。当B组的功能完成并测试通过过，AB组合并，在新架构上开发。
- 局部重构，小步前进。在项目的新功能采用新架构，同时兼容旧功能。在产品迭代的过程中按功能模块逐步迁移旧功能。
上面的方法不一定适用在所有的项目组，具体情况还得具体分析。
