代码重构
【定义】
对软件代码做任何改动以增加可读性或者简化结构而不影响输出结果。
【目的】
增加可读性、增加可维护性、可扩展性。
【关键点】
1. 不影响输出；2. 不修正错误；3. 不增加新的功能性
架构重构
【定义】
通过调整系统结构来修复系统质量问题而不影响整体系统能力。
【目的】
修复质量问题（性能、可用性、可扩展……）。
【关键点】
1. 修复质量问题，提升架构质量；2. 不影响整体系统功能；3. 架构本质没有发生变化。
代码重构 vs 架构重构
| 代码重构 |
||
|
基本做法 |
调整代码 |
调整架构 |
|
目的 |
优化代码，增加代码的可读性、可维护性、可扩展性 |
修复架构质量问题 |
|
是否修复问题 |
否 |
是 |
| 是否改变系统能力 | 否 | 否 |
| 手段 |
引入设计模式 |
引入缓存，分库分表 |
架构重构手段
技巧1 – 先局部优化后架构重构
局部优化
【定义】
对部分业务或者功能进行优化，不影响系统架构。
【常见手段】
1. 数据库添加索引，优化索引；
2. 某个数据缓存更新策略采用后台更新；
3. 增加负载均衡服务数量；
4. 优化代码里面并发的逻辑；
5. 修改 InnoDB buffer pool 配置，分配更多内存；
6. 服务间的某个接口增加1个参数。
架构重构
【定义】
优化系统架构，整体提升质量，架构重构会影响架构的4R定义。
【常见手段】
1. 引入消息队列（增加 Role）；
2. 去掉 ZooKeeper，改为内置 Raft 算法实现（删除 Role）；
3. 将 Memcached 改为 Redis（改变 Role）；
4. 按照稳定性拆分微服务（拆分 Role）；
5. 将粒度太细的微服务合并（合并 Role）；
6. 将服务间的通信方式由 HTTP 改为 gRPC（修改 Relation）；
7. SDK 从读本地配置文件改为从管理系统读取配置（修改Rule）
技巧2 – 有的放矢
1.明确目标：
不要试图解决所有的问题，抓住关键问题。
【技巧】
问题分类：问题收集列表可能有100条，不要全部想着通过架构重构解决，分门
别类，找出需要架构重构解决的问题。
2.明确时间：
要有明确的时间点和里程碑，不要说“慢慢优化”。需要有量化的指标来衡量，不能说“提升 xxx 质量。
【技巧】
独立版本：不要混在业务版本里面做架构重构，否则不好协调资源。
3.明确目标：
需要有量化的指标来衡量，不能说“提升 xxx 质量”。
【技巧】
1. 先收集系统已有相关数据，适合项目投入、时间等；
2. 调查问卷：适合效率、复杂度等。
技巧2 – 案例
技巧3 – 合纵连横
1.合纵：说服业务方和老板。
1. 以数据说话
把“可扩展性”转换为“版本开发速度很慢”，然后给出对应的项目数据。
2. 以案例说话
如果没有数据，就举极端案例，例如某个小功能，开发测试只要5天，但是等了1个月才上线。
1.联横：说服其它团队
1. 换位思考
思考对其它团队的好处，才能让人配合。
2. 合作双赢
汇报和总结的时候，把其它团队也带上。
技巧3 – 案例
技巧4 – 运筹帷幄
1.问题分类：
将问题分类，一段时间集中处理一类问题。
避免对照 Excel 表格，一条一条的解决
2.问题排序
分类后排序，按照优先级顺序来落地。
避免见缝插针式的安排重构任务。
3.逐一攻破
每一类问题里面先易后难。
把容易的问题解决掉，增强信心。
技巧4 – 案例
架构重构的一些典型问题
架构重构是否可以引入新技术？
可以，但尽量少，架构重构要求快准。
业务不给时间重构怎么办？
会哭的孩子有奶吃。
其它团队不配合怎么办？
学会利用上级力量。
业务进度很紧，人力不够怎么办？
收集需要重构的证据，技术汇报的时候有理有据。
原文始发于微信公众号（二进制跳动）：架构重构技巧
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167271.html
