持续重构
ddatsh
什么是重构？？
不改变软件可观察行为的前提下改善其内部结构 —Martin Fowler
通俗说法：看起来没做啥调整，让系统继续更好的满足客户需求。同时，希望重构完成后，这个系统能够多蹦跶几年
重构分类
代码重构
《重构：改善既有代码的设计》、《重构与模式》
现在的程序设计都被框架封装了，设计模式基本是用不到的？
代码风格上，业务代码里充斥着大量的if和else，是否这些逻辑计算应该用策略来代替
大量 for 遍历再处理的场景，是否可用visitor方式处理，比如cat里有大量的应用
架构重构
《软件设计重构》
- 可扩展和负载均衡策略
- db 读写分离和主从切换
- 按需扩容
- 两地三中心多活
- 持续的容量规划
每个阶段都有自己的业务目标
针对业务目标做容量评估，对组件做评估，看当前支撑的量是多少，找到其中的瓶颈点做架构升级。1.5倍到两倍的冗余
把握节奏，太早会影响需求的迭代速度，运维成本高，太晚会不足以支持单量
技术方案长期规划，逐步实施
持续重构，重构在每个阶段都要有人力
- 持续的性能优化
- 性能影响用户的留存率、成本
重构的目标
- 最终目标：更好的承载业务
- 具体目标：改进设计、模型规范、重建生命周期、增大负载能力、提高响应速度、抽象、解耦、无法维护、扩容、业务复杂度、降级开发成本、容易理解、技术栈革新
重构面临的问题
- 新的系统就不会再有问题了么？
- 再过几年，新系统也会变成老系统
- 一个正在运行的系统，如何新老系统平滑迁移？
- 日常需求不停顿，还要花费大量精力重新设计编码
- 之前踩过的坑如果没有很好地沉淀，可能会重新入坑
需要有人为重构负起责任，坚持到底，并承担后果
为什么要重构？
近期问题如：不能支持业务、故障、响应不满足需求、单点无法扩容
长期问题如：维护成本大、扩容成本大、有明显风险、不支持业务扩展
不重构的话，TOP3无法解决的问题
-
如果是平台系统，当初的设计却是为了其中一个业务研发的，功能都是定制化的
-
在不合理的逻辑上叠加需求
-
数据模型不能覆盖目前的需求
当不重构，一改就可能出问题时，按正常的理解：改出来问题是能力的问题，对业务没有很好的把控，对代码没有深入的研究
而实际上重构是因为”坏味道“使得架构和代码本身已经无法阐述它的行为
再通俗点说就是：现有架构和代码，与目前承担的事情不是一个东西
持续重构
- 代码写好之后改进它的设计
- 发现需要添加一个特性，而代码结构使你无法很方便地达成目的，就先重构那个程序，使特性的添加比较容易进行，然后再添加特性
- 重构改进软件设计，代码结构的流失是累积性的
- 重构使软件更容易理解
- 重构帮助找到bug
- 重构提高编程速度
何时重构？
添加功能时、修补错误时、复审代码时
假如交易系统，核心需要稳定。如果重构是维持稳定的必要条件，则需要一个重做级别的重构，需要大量的时间。需要保证重构和需求至少1：1的投入
重构的原则
1、测试优先
2、OCP原则
3、小步快跑，大布局、小迭代
避免过度设计，对于未来的变化，既不要考虑的太多，也不能一点都不考虑
代码满足当前需求，并留有可扩展余地
4.数据
分库分表（横向、纵向）
字段合并、冗余
索引优化、数据缓存
重构注意事项
对系统进行一个生命周期预估
- 未来需求预判
- 模块划分拆解
- 总结历史问题
隐性及显性需求
隐性需求，大家都觉得很不爽，但是又说不出个所以然
视力不同的人看到不同的世界，洞察力不同的人看到不同的需求
割接（新旧系统替换、迁移）实测演练
比如 交易系统重构的割接采用留壳抠瓤的方式，对外接口和暴露方式不变，内部逐渐灰度用重构后的新系统来替换