代码重构思路

背景

1. 项目中我们经常能看到一些上千行的方法，甚至几千行的方法，本人见过最恶心的一个方法3500多行，这些代码逻辑结构复杂，各种if else错综复杂，就算心里万马奔腾最后也得硬着头皮去看、去改，就算上线了也得慌好几天，一听到线上报警心率瞬间飙升。
2. 这些代码很多是因为业务迭代过快，加上一开始没有好好设计，只考虑了完成需求，没有考虑扩展问题。
3. 作为一个有追求的程序员，这种代码正是体现能力的时候，如果能够重构一下，满满的成就感。

难点

1. 不知道如何下手，是从头写一遍还是在原来的代码上改
2. 重构风险过高，没有对业务到达一定的熟悉程度，不敢下手
3. 没有那么多时间去梳理业务细节，隐藏的风险点预估不到
4. 重构的周期可能会很长
5. 重构出问题没人承担责任，如果要我自己承担，不想给自己找麻烦

思路

1. 发现问题代码，首先找到技术负责人说明当前的情况，这样让领导能够知道当前存在的问题，由领导确认要不要重构，因为有些代码非常核心，出问题的话可能责任承担不起，重构过程中可以给你一些建议，不管是业务层面还是方案设计方面。另一方面如果出现问题领导也有一个心理准备
2. 首先需要对当前代码的业务有一个整体的认识，确定影响范围，这样也可以方便告诉测试对应的测试点，出现问题能及时定位
3. 尽管有一些代码逻辑非常复杂，我们可以找到一些代码的边界，对代码进行分块，该提出去的代码就单独提成一个方法，让整个代码结构尽可能的清晰，（这一步我们可以借助于idea的快捷方式，首先选中要提出去的代码，鼠标右键->Refactor->Extract Method，快捷键（Ctrl+Alt+M）），这一步我们对原来的逻辑应该是原封不动的，检查自测没问题可以先上线
4. 做完上一个版本的修改，我们对于很多细节已经隐藏了，出问题的概率已经极大的降低了，接下来我们需要考虑对当前的代码加一些设计模式，加设计模式的目的是让代码尽可能满足开闭原则，方便业务扩展，并且降低影响范围，像什么策略，责任链，可以让你在保留原有代码执行顺序的情况下很轻松的完成代码结构的重构
5. 在上一步的设计模式设计阶段，尽可能的让技术负责人和其他同组的同事帮忙看看合不合适，我们加设计模式的目的是让代码逻辑更加清晰，并且方便扩展，千万不能出现加了设计模式仅仅解决了当前的代码问题，但是后续的扩展难度增加了
6. 通过上面的重构我们的代码的架子已经撑起来了，已经极大的方便了新功能的开发，虽然还有一些被我们隐藏起来的细节，这些需要对业务了解彻底之后再进行
7. 对应隐藏起来的一些细节，我们首先需要去确认这些逻辑是否还有存在的意义，很多逻辑复杂的代码是因为有一些临时的兼容逻辑，这些场景可能都已经不存在了，删掉这些逻辑，代码将会非常清爽（一定要确认清楚，删错代码问题可就大了）
8. 合并业务，有一些业务场景很接近，甚至相同，但是代码写了多套，对于这些代码找出共同点，然后进行合并（这个地方很有可能会出现问题，需要对所有细节有完整的把控，本人就因为疏漏出现过问题）
9. 还有一些大家都比较模糊的逻辑，可以先加上日志上线，观察一段时间之后就有一个大概的了解，如果调用频率非常低，那出现问题的话解决问题就行，应该问题也不会太大
10. 代码重构过程中一定记得要添加一些必要的日志，上线之后需要观察代码运行过程是否符合预期，一旦出现问题首先应该考虑回滚

总结

代码重构并非是一个看起来那么复杂和困难的事情，重点是风险可控，小步快跑，在一个极小的风险范围内首先上线，逐步迭代，风险一定会有，但是一定要最小化风险。