说到重构，我们再来了解一下定义:重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，利用设计思想、设计原则、设计模式编程规范等理论来优化代码。使其更易理解 (可读性)，修改成本更低(可维护性)，提升代码质量。
重构目的:1.重构是时刻保证代码质量的一个极其有效的手段，防止代码腐化。当代码腐化到一定程度，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本。2.优秀的架构和代码是迭代出来的。
时机：持续的重构(做好重构计划，小步快跑，要保证代码仓库中的代码一直处于可运行、逻辑正确的状态.要做好与新功能，老代码的兼容工作。利用静态代码扫描，codeReview做好日常持续重构)。
在“怎么改”这件事儿上，我当时的确做了不少功课，但偏偏“要不要改”这个关键问题脱离了业务，所以成了单方面的“技术自嗨”。这种改进虽说从技术上看十分必要，但业务上优先级却没那么高。
一个需求总是要解决一个业务问题的，在遗留系统中应用假设驱动开发。
我们相信 < 某个功能 >将 < 产生某种结果 >当 < 我们看到某种可度量的信号 > 时，我们就有信心沿着这个方向继续下去。
我们相信，为 < 库存模块添加单元测试 >将 < 提升库存模块的内建质量 >当 < 我们看到库存模块新需求的 bug 数量连续三个月降低 > 时，我们就有信心沿着这个方向继续下去。
明确目标和度量指标
- 业务敏捷：系统快速响应市场变化和新兴机会的能力，比如一个需求从提出到上线的时间；
- 运营效率：系统提升价值流效率的能力，比如一个业务从开始办理到办理完成的时间；
- 客户洞见：系统理解和解释客户数据、行为和反馈的能力，比如前面提到的，客户对于商品视频和直播等特性的敏感程度，我们应该如何去解释；
- 系统韧性与弹性：云时代对于系统的基本要求。 要记得把数据可视化出来，可以打印出来贴在墙上，也可以用一个大显示器立在团队旁边。它们一方面可以激励团队成员，另一方面也是向业务方展示工作的成果，让他们相信，一个看上去很技术向的改进任务，也能给业务带来巨大的价值。
增量演进是指，以增量的方式，不断向明确的目标前进的过程。
重构手法总结为“十六字心法”，非常形象、贴切：旧的不变，新的创建。一步切换，旧的再见。
“旧的不变”是指先不动旧方法；“新的创建”是指创建一个跟原来方法功能相同的新方法，你可以通过先复制再重构的方式，来得到这个新方法，也就是整个系统的一个增量；“一步切换”是指，在充分测试之后，新的方法可以完全替代旧方法了，就将开关切换到新方法上；“旧的再见”则意味着删除旧方法以及相应的开关，一个演进到此也就结束了
我还相信，但是架构调整这么大的动作，怎么可能增量演进呢？”这其实就是我们一直想要强调的，越是大的改进，越要频繁上线去验证，不要等到最后来个“大惊喜”。
当“重”的时候能解决我们有些一知半解的问题，空杯心态对待技术。你真的懂了吗？你真的真的知道吗？你知道的越多,你会发现自己不知道的就会更多。最近看一门课关于结构化表达和思考的，大多数搞IT的可能觉得自己的结构化表达和思考都到位啦，包括我在内。其实不然，真的还有很大差距。最怕自认为自己都懂了，其实只是懂了个皮毛。
