B. 系统重构

B. 系统重构

概述

• 问题
  • 业务已经上线，不能停下来
  • 关联方众多，牵一发动全身
  • 旧架构的约束
• 思路
  • 后台系统重构：解决不合理的耦合
  • 游戏接入系统重构：解决全局单点的可用性问题
  • 系统：解决大系统带来的开发效率问题

项目准备和规划

• 确定重构的目的和必要性
  • 架构重构的原因是什么，是为了满足业务的需要还是只是觉得架构不好看？
  • 除了架构重构之外，还有其他备选方案吗？是否都分析过这些方案的利弊？
• 确定当前的架构状态
  • 你了解当前的架构设计吗？它的设计初衷和之前的选型方案知道吗？
  • 你能给架构设定一个基准状态吗？
• 项目沟通
  • 合纵：产品经理、项目经理沟通
    • 核心：所以在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键！
  • 连横：上下游服务方
    • 原则：换位思考、合作双赢、关注长期
    • PS：不是每个项目都能够推动得了的

具体执行

• 问题收集
  • 收集问题
  • 区分问题的优先级、重要性
  • 问题分类
  • 区分问题的难易程度
• 定义“重构完成”的界限
  • 重构的目标可以量化，或者说可以测试吗？
  • 重构完成的标准是什么？得到业务部门或者领导的认可了吗？
• 渐进式重构
  • 每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易。
  • 每个阶段的工作量不会太大，可以和业务并行。
  • 每个阶段的改动不会太大，降低了总体风险。

项目反馈

• 不要忽略数据
  • 数据对重构的重要性主要体现在两个方面：
    • 在重构设计时，需要考虑业务数据的需求，重构之后的系统对于数据的存储、处理、分析等功能是否有影响；
    • 在重构过程中，考虑依靠数据甚至是实际的数据来验证重构的效果，提供评估的支持。
  • 检查清单：
    • 业务数据的需求在重构设计中有体现吗？
    • 重构过程中能否通过实际数据来验证效果？
• 项目定期反馈
  • 能否把重构过程分成小的迭代，每一次改进都能尽快得到反馈？
  • 重构过程中的效果能够定期展示给业务部门或者领导吗？

注意事项

• 管理好技术债务
  • 架构重构往往是为了偿还技术债务，所以请不要在偿还技术债务的过程中制造技术债务了。
  • 检查清单：
    • 团队对技术债务有跟踪和备忘录机制吗？还是开发人员可以随意的产生债务？
    • 针对技术债务有定期的培训、回顾机制吗？
• 对于代码质量有所掌握
  • 团队成员是否对代码质量有足够的重视？是否有奖惩措施？
  • 团队内部是否有代码质量的标准文档和审查流程？
• 远离那些虚荣的东西（例如使用“热门”的技术栈）
  • 重构的技术选型是否有详实的数据和专家评估？
  • 选用的技术是否有良好的人才积累和足够的经验支持？你是不是实验小白鼠？
  • 在技术选型时，是否至少有两个方案待评估？有没有成熟的技术方案？
• 做好准备面对压力
  • 架构的重构是否得到了管理层（特别是最高管理层）的支持？他们是否对重构的时间、任务量有直接的认识？
  • 你的重构计划中是否包含了一些可以量化的成果？是否定期向管理层展示这些成果？
• 做好面对非技术因素的准备
  • 问题
    • 技术在架构重构（以及其他很关键的公司决策中）的影响因素中并不是最高的，我们还会涉及到商业利益、管理层偏好、大客户影响、办公室zhengzhi、站队问题等等，对于架构师和技术人来说，这些因素往往不是他们所能掌控的。
  • 思路
    • 我们能做的就是，与利益相关者设定重构目标，然后，根据不同的影响因素，调整目标。
    • 请记住，不要死扛这个目标，当有人提出不同的意见时，要坦诚地和他们交流，并告知他们如果采纳意见，那么重构目标会有变化，然后让其他利益相关者也知道这些变化。
    • 非技术因素的影响是客观存在的，而且从商业层面来说也是合理的，所以对于技术人来说要学会适应。
  • 检查清单
    • 当非技术因素影响架构的重构时，你是否对目标做了调整并告知了利益相关各方？
    • 你是否准备以开放而不是抵制的心态来对待非技术因素的影响？