1 代码重构
定义
对软件代码做任何改动以增加可读性或者简化结构而不影响输出结果。
目的
增加可读性、增加可维护性、可扩展性
3 关键点
不影响输出
不修正错误
不增加新的功能性
代码重构时，发现有个功能实现逻辑不合理，可直接修改吗？
当然不可！
2 架构重构
定义
通过整系统结构(4R)来修复系统质量问题而不影响整体系统能力。
目的
修复质量问题（性能、可用性、可扩展…）
关键点
修复质量（架构，而非代码层面的质量）问题，提升架构质量
不影响整体系统功能
架构本质没有发生变化
把某个子系统的实现方式从硬编码改为规则引擎，是代码重构还是架构重构？
属于架构重构，架构设计方案了，实现系统可扩展性。
3 代码重构 V.S 架构重构
4 架构重构技巧
4.0 手段
架构重构是否可以修改 4R 中的 Rank？
不能！修改 rank 就不是重构，而是演进了。拆微服务不属于改 rank。外部系统协作方式都得修改了。比如将淘宝的支付方式支付宝拆出来，成为支付宝公司了。
4.1 先局部优化后架构重构
局部优化
定义：对部分业务或者功能进行优化，不影响系统架构。
常见手段：
数据库添加索引，优化索引
某个数据缓存更新策略采用后台更新
增加负载均衡服务数量
优化代码里面并发的逻辑
修改Innodb buffer pool 配置，分配更多内存
服务间的某个接口增加1个参数
架构重构
定义：优化系统架构，整体提升质量，架构重构会影响架构的4R定义。
常见手段：
引入消息队列(增加 Role )
去掉 ZooKeeper，改为内置 Raft 算法实现(删除 Role)
将 Memcached 改为 Redis( 改变 Role)
按照稳定性拆分微服务( 拆分 Role )
将粒度太细的微服务合并(合并 Role)
将服务间的通信方式由 HTTP 改为 gRPC(修改 Relation )
SDK从读本地配置文件改为从管理系统读取配置(修改Rule )
4.2 有的放矢
案例
开发效率很慢，P业务和M系统互相影响
线上问题很多，尤其是数据类问题
M系统性能很低
有的放矢：
重构只解决第1个问题（开发效率很慢，P业务和M系统互相影响）。其他问题咋办，架构师你不解决了吗？架构重构后了，各个业务部门再解决各自的问题，如 P业务后台优化自己的问题，M 系统优化自己的性能问题，因为这些问题本身靠重构是解决不了的，而是要靠重构拆分之后，各自再继续优化。
4.3 合纵连横
合纵
说服业务方和老板
以数据说话
把“可扩展性”转换为“版本开发速度很慢然后给出对应的项目数据（平时注意搜集数据）。
以案例说话（其实更有效，给人的冲击力更明显）
若没有数据，就举极端案例，如某个小功能，开发测试只要5天，但是等了1个月才上线。
连横
说服其它团队。
换位思考
思考对其它团队的好处，才能让人配合。
合作双赢
汇报和总结的时候，把其它团队也带上。
案例
合纵：告诉PM和项目经理极端案例，设计2周、开发2天、一个月才上线。
连横：P业务线上问题大大减少，P业务不会被其它业务影响
4.4 运筹帷幄
① 问题分类
将问题分类，一段时间集中处理类问题。
避免对照 Excel表格，一条条解决。
② 问题排序
分类后排序，按照优先级顺序来落地。
避免见缝插针式的安排重构任务，不要搭业务的顺风车重构：
避免背锅
效果不明显
无法安排工作量大的重构
③ 逐一攻破
每类问题里面先易后难。
把容易的问题解决掉，增强信心。
④ 案例
Before：
1个100多行的Excel问题表格，一个一个的解决
专挑软柿子捏
见缝插针
After：
分类：性能、组件、架构、代码
分阶段: 优化-> 架构重构 -> 架构演进
专项落地: 明确时间、目标、版本
5 架构重构FAQ
架构重构是否可以引入新技术？
可以，但尽量少，架构重构要求快准。
业务不给时间重构怎么办 ?
会哭的孩了有奶吃。收集数据和案例，事实说话。
其它团队不配合怎么办 ?
学会利用上级力量。上级都不支持，说明你做的这个没意义，所以领导也不在乎。那就别做了。
业务进度很紧，人力不够怎么办 ?
收集需要重构的证据，技术汇报的时候有理有据
6 测试
6.1 判断
代码重构、架构重构、架构演进都不需要去修复问题 ×
微服务拆分既可以是架构重构的手段，也可以是架构演进的手段 √
架构重构应该搭业务版本的便车，可以避免对业务版本有影响 ×
架构重构是为修复问题，因此应该将系统遗留的问题都在架构重构的时候修复 ×
架构重构应该分门别类，按照优先级逐步落地 √
6.2 思考
架构重构的时候是否可以顺手将代码重构也做了 ? 因为反正都安排版本了。No！
局部优化不属于代码/架构重构。
