关于前端:重构把重构后的代码稳定搞上线

代码重构有两大难点，一个是「考古」，也就是如何疾速梳理出代码的原有逻辑，还有一点就是「公布」，如何让新的代码能够稳固的公布到线上，而不产生故障。上面咱们就聊聊我一个敌人的故事，看看他是怎么把代码稳固搞上线的。为了表白更为亲切，你当初就是我那个敌人。

重构代码对很多人来说，相对是一件脏活、累活。没有能够大幅度提效的办法，难以积淀无效的体系化的可复用的技术抓手，对业务来说没有显著的增量，精力和工夫耗费微小，没有测试用例，也不肯定能失去测试的反对，自测很难做到充沛，最初开发完了很难上线，次要起因是胆怯！当然并不是咱们不自信，是真的恐怖。

一、你为什么不敢发代码？

通过代码还原过后残缺的产品逻辑太难了

你重构的代码是谁的？鬼晓得是谁的！能让你重构的代码大概率不是你写的代码，而且是远古代码，用的是一种过期的技术栈。当然个别状况下，当年的开发、测试、甚至产品早已不见了形迹，只能在正文的代码里看见了了数语。语言中走漏着无奈，用一个程序员的良心揭示着起初人，「小心后面的脏东西」。看了这些话，你只能发出口中马上要吐出的芳香，默默来到工位，倒点热水。

从此你会发现，正文不仅可能帮你读懂代码，还能有警示作用，通知你重构代码的同时，记得把 bug 一并改了。你想要通过正文来梳理出原始需要的欲望宣告失败，接下来你只能死磕了，祷告千万不要漏掉业务逻辑。

没有自测用例

别以为大公司制度欠缺，测试都有残缺的测试用例，事实会狠狠的夹你脑门。频繁的迭代，性能早已面目全非，老的用例基本不可用，更何况基本找不到老的测试用例。没有用例怎么自测呢？全靠集体设想。

没有测试同学跟进

多一个人多一分力量，让一个有教训的测试参加到性能回归中来，无疑会给你的重构事业吃上定心丸，但实在的状况是，测试同学基本不想参加这种脏活累活。他本人手里的需要还测不过去，怎么会把工夫奉献给一个前端发动的重构工作上呢。无增量，无抓手，纯膂力，他们同样心知肚明。

没有稳固公布计划

在没有上述保障的前提下，如果你还能硬着头皮上线，就会遇到更大的难题，如何上线？间接全量替换吗？如果线上出问题怎么办？好在前端的回滚是十分迅速的，然而即便再迅速的回滚，从公布实现到发现问题回滚，在揭示用户从新刷新页面，这个过程也足以造成难以估计的结果，尤其是那些高频应用，且极易产生脏数据的场景。这就是没有一个无效的公布计划所导致的常见结果，这个结果还有可能导致你背上故障，这一年加过的班，熬过的夜，掉的头发，什么也换不来，只能催生你换个中央重新做人的念头。

综上因素间接导致开发者极度不足安全感，一个不敢上线本人代码的程序员，就像中午被本人一个月大孩子的哭声吵醒，那时那刻你只想装死摸鱼。更何况你的工作往往不是只有重构这一件事，写写新需要他不香吗？就这样你眼看着一个页面重构了两个星期，迟迟不能收尾，你变得越来越不自信，越来越胆怯了起来，不敢面对那些重构了一半的代码，开始恐怖老板的问题：「重构搞的怎么样了？」，你几乎不像个程序员。

终于到了年底，你的重构事业还未实现，更可怕的是，这件事还被打上了「承诺型」OKR 的标，于是你痛定思痛，做了个梦。

工夫回到年初你刚刚接到重构工作的时候。

二、寻求组织保障

你的重构工作是把 177 个 jQuery 页面用 React 重写一遍。你立马想到，本人一个人一年工夫，肯定是做不完的，此时此刻，切记不要满口答应，肯定捕风捉影，甚至向着最坏的方向想，让老板充分认识到这项工作的艰巨性，不要抱有太高的冀望。最重要的是保障人力的投入，必须有更多的同学一起参加进来，无效的分工才有可能实现这项艰巨的工作。有人参加进来，也只是根底，因为他们极有可能会像下面形容的一样，从兴高采烈到气宇轩昂，因而肯定要确保工夫的投入，必要时把老板也拉进来跟你一起做，老板一旦参加进来，就会更有体感，能领会到大家的不易。接下来，就应了那就老话，「别忘了，你是一个 owner！」做好基础设施建设，让每个同学有趁手的工具，有平安的保障，去除他们的后顾之忧至关重要。因而，你要做上面几件事。

三、划分重构页面优先级

你通过粗疏的钻研发现，这些页面中，有 77 个页面是用户应用较多的页面，也是绝对比较复杂的页面，剩下的 100 个页面，大部分是给开发用的增删改查页面，用户的应用频率不高。于是你做了如下划分：

优先级划分好优先级当前，就要对不同优先级的页面应用不同的稳固公布策略。

• 简单高频页面：重兵压上，粗疏还原原始需要，抠代码，拉测试同学一起整顿测试用例，依照测试用例自测，测试同学回归所有性能。但其实这部分页面中，也能够分为两种页面：

  • 编辑页面：这样的页面是危险最高的页面，一旦因为后端接口没有做残缺的数据校验，就会编辑出脏数据，或者谬误的数据被保留，导致线上运行异样，这种结果将是不堪设想的，即便十分短的工夫内回滚，也会造成难以挽回的故障，因而必须要像新需要一样测试到位。
  • 展现页面：这样的页面不会影响运行时，不会产生脏数据，是危险绝对低一点点的页面，本着不麻烦合作方的准则，毕竟资源无限，能够让测试帮你出残缺的用例，而后你本人自测，或者多找几个同学帮你自测。
• 高频简略页面：自测，当然最好是能绑架几个常常用这个性能的开发，来帮你点点，然而本人测总是会有可能会有脱漏，因而就须要上面的步骤来保障了。
• 低频运维页面：选择性重构，因为很多页面基本上不会有迭代，且应用频率较低，基本上不须要重构，即便是有新的需要，也能够在做新需要的时候顺便重构下，认为并不能占用太多工夫。

将页面划分结束后，你会发现重构的工作量升高了很多，因为本着「无需要，勿变更」的准则，很多页面都能够不须要重构。且上述重构完的页面都必须做灰度公布。

四、单测

前端不太喜爱写单测，你大略总结了一下，次要有上面几方面的起因：

• 当下的收益不高。
• 相比后端接口的单测，前端单测写起来绝对简单。
• 前端更多是面向 UI 的编程，但 UI 变动大，难以使用 TDD (测试驱动开发) 的开发模式。
• 没有写单测的习惯，可能是因为单测减少了工作量，且没有写纯函数的意识，不利于测试。
• 单测的工具难学又难用。

你发现前端不喜爱写单测，有各种各样的起因，然而当你重构那些简单页面，尤其是 jQuery 技术栈重构为 React 技术栈的时候，单测真的十分有用。

比方这里有一个编辑页面，蕴含两局部：根本信息和运行逻辑，在重构运行逻辑时候，你首先要保障的是重构过后的页面在保留的时候，保留的数据结构必须跟之前的接口参数必须统一，所以在重构运行逻辑这个组件的时候就会有很多数据转换逻辑。

能够看到为了保障你的新组件不影响放弃原有性能，就要保障原始数据通过新组件的一顿操作最终保留了原来的构造，此时你就能够写单测来保障这个过程。

describe('utils', () => {it('流程图：转换为提交的数据 transformForm', () => {const result = transformForm(canvasData);
    expect(result).toEqual(settingData);
  });

  it('流程图：转换为须要的数据 parseRuleSetData', () => {const [result] = parseRuleSetData(settingData, rules);
    expect(result).toEqual(canvasData);
  });

  it('流程图：重复转换 transformForm - parseRuleSetData', () => {const [result] = parseRuleSetData(visualSettings, rulesData);
    const newResult = transformForm(result);
    expect(newResult).toEqual(visualSettings);
  });
});

前端单元测试写起来简单，其实只是 UI 的单测简单而已，如果你把代码做好了足够的拆分，拆出更多函数，更多 hooks，单测就是轻而易举了。

五、测试用例

你在的团队，始终测试资源都不是短缺，测试用例仿佛始终都是一种可遇不可求的货色，尤其是在麻利开发的趋势下，产品性能变动快，很少有测试会始终去保护那个最后的测试用例，往往是写过用过就再也找不到了。但测试用例在重构这个场景下，真的十分重要，他解决的外围问题是把测试同学拉到重构的品质保障中，一起梳理老的逻辑。
这份贵重的测试用例，能够成为你自测的根据，也能够为你提供对于同一个性能的不同视角，如果你通过代码看到的是实现细节的逻辑，那测试看到的就是整个链路的流程图。很多中后盾零碎都有治理态和运行态之分，治理态，前端是十分相熟的，然而运行态，测试往往更加相熟。

六、自测

拿到测试用例，你就能够自测了，然而这里有个坑，就是如果你齐全依赖测试同学给你的测试用例。只有保障测试用例验证通过就行了，这种想法会出大问题，因为负责这块性能的测试可能是个老手，可能并不是始终负责这块性能的测试，他们的测试用例可能只是浮于外表的。所以你须要把通过代码考古发现的测试用例里没有的逻辑，裸露给测试同学，并补充到测试用例里。并且如果发现有一些看不懂的逻辑，就应该搞懂他，那些你不懂的死角，往往上线后就会有大问题，不要心存侥幸。
自测十分重要，然而往往你会感觉开发完了，就算是把这个事做完了，而后就去忙别的事了，并没有好好的自测，心想还有测试呢，等他们提问题，我再改吧。这是一种很广泛的程序员心理，其实很难防止，毕竟事件有很多。这个时候你能够找同组的开发同学帮你点一点，先解决那些不言而喻的问题，也算是一个认真负责的程序员了，不要让测试同学给你提太多低级 bug。

七、回归测试

能有测试同学帮你做性能的回归测试真是一件可遇而不可求的事，肯定要珍惜，拿出你的大块工夫配合好。这其中最重要的就是多交换，测试同学也不肯定晓得所有的逻辑，在做回归测试的时候，就须要开发和测试重复核查每个逻辑死角，弄清楚，才敢上线。
当然，可能有测试帮你回归的性能都是极易引起故障的性能，这里就有一个技巧就是如何拉测试参加你的重构中来。像这样重要的性能如果测试晓得外面的逻辑，你能够怀着求教的心态去问对方，如果对方并不理解，那你就能够讲给他听，一个负责任的测试，应该都十分想理解本人负责零碎的重要模块的前因后果。

八、灰度公布

即便你做了再多的测试，都有可能有没有思考到的脱漏点，这个时候灰度就十分重要了，灰度就必须要有灰度工具才行。重构个别是以页面或者区块为粒度依照人来进行的。所以你的灰度工具必须要蕴含这些性能：

• 配置用户或者用户组
• 配置老路由和新路由
• 配置灰度状态提醒
• 新老页面的主动打点

灰度配置页面，新老动静路由的参数须要保持一致，这样能力把参数传递上来。

展现灰度提醒，并提供一个疾速「返回旧版」的按钮，为了更疾速解决问题，能够给出开发者联系方式。

当用户拜访老路由的时候，依照灰度配置验证以后用户是否在灰度中，如果在灰度中，则立刻跳转到新的路由，并显示灰度提醒。如果重构的是页面中的区块，则能够提供灰度命中的办法，在页面调用区块的局部做判断。

灰度策略能够依照以下用户级别散布进行：

• L1：所有我的项目开发，测试，设计师，外部经营人员
• L2：外围用户，建设钉钉群，察看用户反馈，及时解决用户问题。
• L3：适当退出更多用户，直到全量后，删除灰度策略的配置。

公布后，留神察看打点数据：

打点的时候须要留神，要依照动静路由来打点，并分成命中灰度的，点击应用旧版的，不在灰度内的三个维度来看数据，同时 每天 调整灰度用户，这样就能保障页面是有人用的。如果有很多用户应用了返回旧版的性能，那你就得找找这些用户理解下状况了，到底是有 bug 还是交互不难受，一对一的解决用户问题，在重复去优化你的页面，缓缓扩充用户灰度范畴，直到老的路由拜访数据 PV 为 0。

九、全量上线

全量上线并不是灰度所有人，而是真正下线老的页面，并删除老的代码，只有到这一步才算重构实现了。

十、总结

经验千难万险，你终于把重构好的页面上线了，经验了这个过程，感叹良多，只求当前再也不要做重构了，好好做需要不香吗？后头看看整个过程，要想重构的页面上线，不仅要下苦功夫，还要克服兽性的一些弱点，要做到这几点：

• Double Check：让其他人参加进来，多一个人就能帮你发现更多问题。重构背后，不要置信本人，置信搭档。
• 逻辑无死角：不要还有不懂的代码，不分明的逻辑，依照程序员的第六感，不确定的都会出大问题。
• 集中注意力：重构不能碎片化进行，要集中大块工夫来做，并一做到底，不然过个几天，你本人的代码都会不意识。
• 一跟到底：开发实现不是重点，全量上线，并下掉老的页面才是完结。

致敬每一位重构路上的壮士。

作者：ES2049 / 黑石

文章可随便转载，但请保留此原文链接。
十分欢送有激情的你退出 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com。