什么是重构??

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

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

重构分类

代码重构

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

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

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

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

架构重构

《软件设计重构》

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

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

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

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

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

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

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

重构的目标

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

重构面临的问题

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

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

为什么要重构?

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

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

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

  1. 如果是平台系统,当初的设计却是为了其中一个业务研发的,功能都是定制化的

  2. 在不合理的逻辑上叠加需求

  3. 数据模型不能覆盖目前的需求

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

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

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

持续重构

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

何时重构?

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

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

重构的原则

1、测试优先

2、OCP原则

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

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

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

4.数据

分库分表(横向、纵向)

字段合并、冗余

索引优化、数据缓存

重构注意事项

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

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

隐性及显性需求

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

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

割接(新旧系统替换、迁移)实测演练

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