架构重构的复杂度

• 业务已上线：不能中断
• 关联方众多：牵一发动全身
• 旧架构约束（主要是旧架构上产生的数据）

如何判断架构是否需要重构

• 系统不断出现各种问题
  • 系统响应慢
  • 数据错误
  • 用户访问失败
  • 宕机
  • 数据库瘫痪
  • 数据丢失
  • 开发效率越来越低
  • ……等
• 长期针对性解决出现的问题而无法达到预期效果

重构核心思路

有的放矢

1. 分析、总结系统当前存在问题
2. 从一大堆问题识别出真正需要通过重构来解决的问题（可能不必要全部重构）
3. 集中力量快速解决

合纵连横

• 原因：重构占用大量资源，影响业务功能开发等

合纵（针对上下游非技术人员）

• 核心思想
  • 把问题阐述清楚，达成共识
    • 技术术语转化（术语领域性较强，有时候较难理解）
      • 术语转通俗语言（可扩展性不好 -> 版本开发速度很慢，每次开发都需要考虑会不会影响原有功能）
      • 拿数据说话（收集之前版本开发时的周期、甘特图等）
      • 使用案例佐证

连横（针对同级、同部门、不同部分但需要配合的技术人员）

• 来自小伙伴的阻力
  • 这对我有什么好处？
    • 核心思想
      • 换位思考、合作双赢、关注长期
        • 站在对方角度思考，能给对方带来什么好处
        • 实在没好处则需要上级来推动

运筹帷幄

• 核心思想：分阶段解决问题
  • 好处
    • 每阶段目标明确（团队信心足）
    • 每阶段工作量不会太大（对业务功能开发影响小）
    • 每阶段改动不会太大（降低总体风险）
  • 如何制定分段实施策略
    • 分析问题
    • 按优先级排序
    • 对问题进行分类
    • 先易后难
      • 先解决了简单的问题，难的问题看起来也不会那么复杂了
      • 更快的看到效果
      • 根据已解决的问题更快速的调整方案细节（方案确定了未必就是正确且最优的，可能需要调整）
    • 循序渐进
      • 阶段拆分以 1 到 3 个月为佳