什么是重构？？

不改变软件可观察行为的前提下改善其内部结构 —Martin Fowler

通俗说法：看起来没做啥调整，让系统继续更好的满足客户需求。同时，希望重构完成后，这个系统能够多蹦跶几年

重构分类

代码重构

《重构：改善既有代码的设计》、《重构与模式》

现在的程序设计都被框架封装了，设计模式基本是用不到的？

代码风格上，业务代码里充斥着大量的if和else，是否这些逻辑计算应该用策略来代替

大量 for 遍历再处理的场景，是否可用visitor方式处理，比如cat里有大量的应用

架构重构

《软件设计重构》

可扩展和负载均衡策略
db 读写分离和主从切换
按需扩容
两地三中心多活
持续的容量规划

每个阶段都有自己的业务目标

针对业务目标做容量评估，对组件做评估，看当前支撑的量是多少，找到其中的瓶颈点做架构升级。1.5倍到两倍的冗余

把握节奏，太早会影响需求的迭代速度，运维成本高，太晚会不足以支持单量

技术方案长期规划，逐步实施

持续重构，重构在每个阶段都要有人力

持续的性能优化
性能影响用户的留存率、成本

重构的目标

最终目标：更好的承载业务
具体目标：改进设计、模型规范、重建生命周期、增大负载能力、提高响应速度、抽象、解耦、无法维护、扩容、业务复杂度、降级开发成本、容易理解、技术栈革新

重构面临的问题

新的系统就不会再有问题了么？
再过几年，新系统也会变成老系统
一个正在运行的系统，如何新老系统平滑迁移？
日常需求不停顿，还要花费大量精力重新设计编码
之前踩过的坑如果没有很好地沉淀，可能会重新入坑

需要有人为重构负起责任，坚持到底，并承担后果

为什么要重构？

近期问题如：不能支持业务、故障、响应不满足需求、单点无法扩容

长期问题如：维护成本大、扩容成本大、有明显风险、不支持业务扩展

不重构的话，TOP3无法解决的问题

如果是平台系统，当初的设计却是为了其中一个业务研发的，功能都是定制化的
在不合理的逻辑上叠加需求
数据模型不能覆盖目前的需求

当不重构，一改就可能出问题时，按正常的理解：改出来问题是能力的问题，对业务没有很好的把控，对代码没有深入的研究

而实际上重构是因为”坏味道“使得架构和代码本身已经无法阐述它的行为

再通俗点说就是：现有架构和代码，与目前承担的事情不是一个东西

持续重构

代码写好之后改进它的设计
发现需要添加一个特性，而代码结构使你无法很方便地达成目的，就先重构那个程序，使特性的添加比较容易进行，然后再添加特性
重构改进软件设计，代码结构的流失是累积性的
重构使软件更容易理解
重构帮助找到bug
重构提高编程速度

何时重构？

添加功能时、修补错误时、复审代码时

假如交易系统，核心需要稳定。如果重构是维持稳定的必要条件，则需要一个重做级别的重构，需要大量的时间。需要保证重构和需求至少1：1的投入

重构的原则

1、测试优先

2、OCP原则

3、小步快跑，大布局、小迭代

避免过度设计，对于未来的变化，既不要考虑的太多，也不能一点都不考虑

代码满足当前需求，并留有可扩展余地

4.数据

分库分表（横向、纵向）

字段合并、冗余

索引优化、数据缓存

重构注意事项

对系统进行一个生命周期预估

未来需求预判
模块划分拆解
总结历史问题

隐性及显性需求

隐性需求，大家都觉得很不爽，但是又说不出个所以然

视力不同的人看到不同的世界，洞察力不同的人看到不同的需求

割接（新旧系统替换、迁移）实测演练

比如交易系统重构的割接采用留壳抠瓤的方式，对外接口和暴露方式不变，内部逐渐灰度用重构后的新系统来替换