架构重构

1.有的放矢

    只有少部分架构演化可能需要推到重来，绝大部分的架构演化都是通过架构重构来实现的。

1.1 架构重构的难点

    • 业务已经上线，不能停下来

    • 关联方众多，牵一发动全身

    • 旧架构的约束

1.2 架构重构案例

    架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。

    • 后台系统重构：解决不合理的耦合

    • 游戏接入系统重构：解决全局单点的可用性问题

     • X 系统：解决大系统带来的开发效率问题

    判断到底是采取架构重构还是采取系统优化的简单方法：假设我们现在需要从 0 开始设计当前系统，新架构和老架构是否类似？如果差异不大采取系统优化即可；如果差异很大就进行系统重构

非架构重构问题不能放任不管。建议在重构完成后，启动多个优化项目去优化。

 

2.合纵连横

2.1 合纵

    • 推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通，要和利益相关方沟通好，让大家对于重构能够达成一致共识

    • 和非技术人员沟通时不能用技术术语：可扩展性、可用性、性能、耦合、代码很乱……

    • 在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键，统计版本讨论时长、开发时长、故障次数、每次影响时长、影响用户数量、客服反馈意见数量等

2.2 连横

    • 在需要和其他相关或者配合的系统的沟通协调时，都是做技术的，有比较多的共同语言，但主要的阻力来自“这对我有什么好处”和“这部分我这边现在不急”

    • 对于“有什么好处”的问题，有效的策略是“换位思考、合作双赢、关注长期”。简单来说就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益

    • 对于“现在不急”的问题，要么是没有达成一致意见，要么是真的有更重要的事情，解决方案除了换位思考统一意见外，还可以分阶段处理，先做其他需要重构的，但最好明确具体的等待时间，如3 个月后开始、6 月份开始

 

3.运筹帷幄

3.1 让架构重构落地

    • 架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题