来源：蚂蚁金服·数据体验技术团队
作者：新茗
编辑：念忧
前言
之前也介绍过我们团队的前端项目从零开始经历8个月迭代业务代码10万行(仅为产品长期规划需求的20%)，至今仍然在不断迭代的过程。
团队成员除了设计好的架构来管理这种复杂度极高的前端应用，还开始补充设计模式以及重构方面的知识，目的是为了让项目代码在不断迭代的过程中优化项目代码，保持代码的新鲜度，鲁棒性，可维护性… 让后续加入的团队新人也可以快速加入我们的产品开发中
PS: 不管对于何种语言，重构都是软件开发过程中不可或缺的一部分。如果已经了解重构的基础，可以直接跳往至文章后面的重构案例部分。
重构背景
“如果尿布臭了，就换掉它”。随着业务需求的不断加入，代码随着时间的推移变得越来越糟。这其中可能包括以下坏味道(仅列举):这种情况容易出现冗余代码。比如如果类内出现了多个变量带有相同的前缀或者后缀，这意味着你可以考虑把他们提炼到某个组件内，或者考虑这个组件是否可以成为子类，使用提炼类的手法来重构。当子类没有做足够的工作的时候，或者说在可见的预期内，不会有新的情况出现，考虑将类内联化。遵循一条原则: 每当感觉需要注释来说明什么的时候，可以尝试将需要说明的东西写进一个函数中重复的代码过长的函数冗赘类过长的类什么是重构我们回过头来看一下"什么是重构"不改变软件可观察行为的前提下，改善其内部结构以提高理解性和降低修改成本
摘自《重构 - 改善既有代码的设计》(下面简称《重构》)
何时重构？我们需要明确的一点是: 重构不是一件应该特地拨出一段时间来做的事情。重构不是目的，但是重构可以帮助你把事情做好。
事不过三，三则重构重复性工作，既有的代码无法帮助你轻松添加新特性时修补bug时，排查逻辑困难code review 可以让他人来复审代码检查是否具备可读性，可理解性太多的代码无注释，已然连自己都无法快速理清代码逻辑重构的衡量指标数量: 代码的行数质量: 代码复杂度，耦合度，可读性，架构依赖复杂度等成本: 花费的时间回报(成果): 支持后续功能的快速叠加，解决现有因代码设计问题无法优化的矛盾等抓重点 抓重点啦说了这么多废话，其实大家都明白没有与实践结合的理论都是空虚的。但是
重构和设计模式一样，也是需要一个"学习——领悟——突破"的过程。第一步的学习让你了解基本的重构手法，第二步的实践勾起你对重构手法的回忆以及重温应用，第三步的应用以及实践经验激发你的思考，领悟以及总结，以致于灵活运用。但凡是人，总是在不断学习，不断温习，以达到具体场景具体应用，灵活自如。 重构是一个很大的话题，《重构》作者本人也是经历了N多的项目，以及多年的经验才总结出来的重构技巧。重构技巧《重构》一书作者总结的重构手法实在是太多了，只能通过图片来展示一下所有作者总结的重构列表。 具体的补充，大家可以看看《重构》一书。重构的实践作者推荐的一种做法:随机挑选一个目标先给自己选择一个目标(譬如“去掉一堆不必要的子类”),然后朝着目标前进，每一步走得小而坚定没把握就停下来当你无法证明自己所做的一切能够保证原有程序的逻辑和语义时，请你停下来思考：既有的重构是改善了还是毫无成果需要撤销。保证每次重构后的测试都能正常跑通作为开发者, 应当把重构作为开发的一部分，一边开发一边重构。在快速堆叠代码，实现基本需求功能的基础上，写好测试用例，保证功能不变，逐步重构。 这也是我们团队要求每个人都掌握重构这门必备技能的原因。优秀的程序员应当尽量避免低质量的代码。重构案例故事场景有三种类型的电影，顾客可以进行租赁租赁规则价格计算规则： 普通片儿 —— 起步价2¥，超过2天的部分每天每部电影收费1.3元 新片儿 —— 每天每部3元 儿童片 —— 起步价2¥，超过3天的部分每天每部电影收费0.8元积分计算规则： 每借一部电影积分加1，新片每部加2原始代码CODEPEN程序结果:（请保证重构后结果不变～）
类图
3
有兴趣的可以先看看原始代码，考虑一下其中的原始对象关系，再行考虑如何重构代码。 原始代码其实是有很多问题可以挖掘的，下面是我们的讨论整理:
划分职责关系，遵循单一职责原则解法1:6.1 Extract Method(提炼函数)—— 最常用的重构手法解法2:9.1 Decompose Conditional(分解条件表达式)statement打印账单函数承担了很多功能，包括收费计算，积分计算以及结果展示等等用户类中承担了不属于它的职责，包括：收费规则、积分规则。这些职责应该是属于电影类型的。整理清楚其中的业务逻辑，比如收费规则和积分规则 - 见故事场景不要直接访问对象的数据。容易发生其他对象改变该对象的数据，而拥有该数据的对象却一无所知。解法：8.10 Encapsulate Field(封装字段手法)—— 使数据和行为想分离重构不应该被外界所感知，保证testcases依然可行部分重构这里为了更好的展示重构的手法，使用TS，根据上面的讨论进行了部分重构，重构的方式其实是根据业务未来的扩展方向而定，并没有最优解，有兴趣的可以加入我们，抛出你的见解～CODEPEN执行结果:
重构后的类图关系
基本技巧小步前进，频繁测试(保证足够的测试来支持你的重构行动)使用智能开发工具（比如VSCode右键可以将过长的函数代码拆解函数化）推荐书籍《代码整洁之道》《重构 - 改善既有代码的设计》《修改代码的艺术》《代码大全》
原文链接：/ProtoTeam/blog/blob/master/01/3.md
