记录下代码重构怎么做更稳妥的思考

    对于Android移动端的技术发展来说，现在已经到了较为成熟的阶段，出现了很多航母级应用，比如阿里系、字节系、腾讯系、金山系等等，数不胜数。技术发展很快，但早期的技术并没有现在这么成熟，毕竟需求一直处于变化迭代中，原来的架构可能早已无法满足现阶段的需求背景。所以我们日常开发经常会穿插一些代码重构的工作，这些编码工作一般有以下特点：

• 祖传代码，很难把控。
  很多业务逻辑是经过很多个版本迭代走到现在的，可能当初负责的同事都换了好几波了，文档也并没有记录的那么完善，无从回溯。只能闷头看代码了解老逻辑，但是老代码想读懂，让人心里很没有底，懂得都懂，唔…。
  

• 改动量大，review代码不容易发现问题。
  娜代码位置、重命名、提取函数、拆分类职责等等，动辄就是几百个changes，让人MR代码心里都没底，瑟瑟发抖。所以一听要让重构某个模块，有时候内心并非不想让代码变得更好，而是”不敢改，对业务熟悉程度不够的情况下很容易出线上bug“
  
  程序员：我就改了一行。。。

• 影响面难把控
  改动量大势必导致影响面广，对于自测和测试同学都是很大的工作量，如果在重构时影响面的评估有所遗漏，那就得翻车了。

那咋办，要不推翻重写吧。。。

1. 追本溯源，清楚逻辑

    既然确定要重构了，那硬着头皮也要先了解老的逻辑是什么样的。千万别偷不该偷的懒，就算没法面面俱到，也要有整体的把握才能开始行动。这期间，可以通过画流程图、序列图等工具帮助梳理旧的逻辑。

2. 代码未动，方案先行

    在熟悉了老代码逻辑后，先根据重构的范围进行方案的规划，然后找熟悉业务的同事，项目组长、领导参与重构方案评审，有问题及时完善，有风险点也要及时记录下，并评估怎么解决。

3. 及时记录改动点、影响面

    开始进入重构编码后，每改动一个功能逻辑点，都要及时的记录改动点和影响面，存档留给自测和测试同学参考，方便进行有侧重点的展开测试工作。

4. 改完一个点，要自测自测自测

    提到自测这个事，我心里是一把辛酸泪。刚开始工作时，心里想着有专业的测试同学在，我仔细检查代码，然后发现没有问题就直接自测用例填通过就好，不用每个点都实际的去操作、去模拟场景。因为很多场景是很难mock出来的，有的一个用例环境都能凑两小时，抓狂，还有很多情况下测一次，场景条件就被重置了，再测另外一个case又得再搞一次环境，绝了。这时候偷个懒，还节省出时间做其他需求了。按照这样的做法走到提测流程，然后测试同学有时候拿到一测就出问题了，还是开发时没想到的情况，这时候心里就是大写的尴尬。测试同学就会问，“你有自测吗，如果没有别提交给我行吗？”，瞬间就尬住了，惨痛的代价。

5. 最小化commit，message要规范清晰

    最后是本地自测都没问题了，提交代码时别集中在一个commit里提交，每完成一部分代码，到了开发的一个阶段就先提交了，并且在commit message中描述清楚提交的内容。这样做的好处：

• 一来是防止本地的修改太多，一股脑的提交容易出错，或者多提交了测试代码，或者操作不当本地改动搞丢了。
• 二来，将来遇到了难定位的bug也能参考当时的commit message，去缩小定位范围，也可更快确定是哪条commit导致的，再者可以在其他人阅读代码时辅助理解这段改动有什么作用。