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！
局部优化不归于代码/架构重构。
