B. 系统重构
概述
- 问题
- 业务已经上线,不能停下来
- 关联方众多,牵一发动全身
- 旧架构的约束
- 思路
- 后台系统重构:解决不合理的耦合
- 游戏接入系统重构:解决全局单点的可用性问题
- 系统:解决大系统带来的开发效率问题
项目准备和规划
- 确定重构的目的和必要性
- 架构重构的原因是什么,是为了满足业务的需要还是只是觉得架构不好看?
- 除了架构重构之外,还有其他备选方案吗?是否都分析过这些方案的利弊?
- 确定当前的架构状态
- 你了解当前的架构设计吗?它的设计初衷和之前的选型方案知道吗?
- 你能给架构设定一个基准状态吗?
- 项目沟通
- 合纵:产品经理、项目经理沟通
- 核心:所以在沟通协调时,将技术语言转换为通俗语言,以事实说话,以数据说话,是沟通的关键!
- 连横:上下游服务方
- 原则:换位思考、合作双赢、关注长期
- PS:不是每个项目都能够推动得了的
- 合纵:产品经理、项目经理沟通
具体执行
- 问题收集
- 收集问题
- 区分问题的优先级、重要性
- 问题分类
- 区分问题的难易程度
- 定义“重构完成”的界限
- 重构的目标可以量化,或者说可以测试吗?
- 重构完成的标准是什么?得到业务部门或者领导的认可了吗?
- 渐进式重构
- 每个阶段都有明确目标,做完之后效果明显,团队信心足,后续推进更加容易。
- 每个阶段的工作量不会太大,可以和业务并行。
- 每个阶段的改动不会太大,降低了总体风险。
项目反馈
- 不要忽略数据
- 数据对重构的重要性主要体现在两个方面:
- 在重构设计时,需要考虑业务数据的需求,重构之后的系统对于数据的存储、处理、分析等功能是否有影响;
- 在重构过程中,考虑依靠数据甚至是实际的数据来验证重构的效果,提供评估的支持。
- 检查清单:
- 业务数据的需求在重构设计中有体现吗?
- 重构过程中能否通过实际数据来验证效果?
- 数据对重构的重要性主要体现在两个方面:
- 项目定期反馈
- 能否把重构过程分成小的迭代,每一次改进都能尽快得到反馈?
- 重构过程中的效果能够定期展示给业务部门或者领导吗?
注意事项
- 管理好技术债务
- 架构重构往往是为了偿还技术债务,所以请不要在偿还技术债务的过程中制造技术债务了。
- 检查清单:
- 团队对技术债务有跟踪和备忘录机制吗?还是开发人员可以随意的产生债务?
- 针对技术债务有定期的培训、回顾机制吗?
- 对于代码质量有所掌握
- 团队成员是否对代码质量有足够的重视?是否有奖惩措施?
- 团队内部是否有代码质量的标准文档和审查流程?
- 远离那些虚荣的东西(例如使用“热门”的技术栈)
- 重构的技术选型是否有详实的数据和专家评估?
- 选用的技术是否有良好的人才积累和足够的经验支持?你是不是实验小白鼠?
- 在技术选型时,是否至少有两个方案待评估?有没有成熟的技术方案?
- 做好准备面对压力
- 架构的重构是否得到了管理层(特别是最高管理层)的支持?他们是否对重构的时间、任务量有直接的认识?
- 你的重构计划中是否包含了一些可以量化的成果?是否定期向管理层展示这些成果?
- 做好面对非技术因素的准备
- 问题
- 技术在架构重构(以及其他很关键的公司决策中)的影响因素中并不是最高的,我们还会涉及到商业利益、管理层偏好、大客户影响、办公室zhengzhi、站队问题等等,对于架构师和技术人来说,这些因素往往不是他们所能掌控的。
- 思路
- 我们能做的就是,与利益相关者设定重构目标,然后,根据不同的影响因素,调整目标。
- 请记住,不要死扛这个目标,当有人提出不同的意见时,要坦诚地和他们交流,并告知他们如果采纳意见,那么重构目标会有变化,然后让其他利益相关者也知道这些变化。
- 非技术因素的影响是客观存在的,而且从商业层面来说也是合理的,所以对于技术人来说要学会适应。
- 检查清单
- 当非技术因素影响架构的重构时,你是否对目标做了调整并告知了利益相关各方?
- 你是否准备以开放而不是抵制的心态来对待非技术因素的影响?
- 问题