共计 6208 个字符，预计需要花费 16 分钟才能阅读完成。
在软件工程学中重构就是在不扭转软件现有性能的根底上，通过调整程序代码改善软件的品质、性能，使其程序的设计模式和架构更趋正当，进步软件的扩展性和维护性。
摘要
在本文中，您会理解到如下的内容：
先增加新性能还是先进行重构？
重构到底有什么价值？
如何评判这些价值？
重构的机会是什么？
如何进行重构？
1. 先增加新性能还是先进行重构？
问题：
官网材料，重构剖析 1.0 版中。
有两顶帽子，一个是增加新性能，一个是重构
增加新性能时，你不应该批改既有代码，只管增加新性能，重构时你就不能再增加性能，只管改良程序结构。
一次只做一件事件。
这两个是否有矛盾，以哪个为准？后面有些可信资料版本不一，有的还要相互打架，是否能够对立一下？
回复：
对于增加新性能和重构是否矛盾的问题，是先增加新性能还是先进行重构？
咱们要做的是察看这两个事件哪个更容易一些，咱们要做更容易的那一个。
就是你 不能一下子同时做这两件事件。因为同时做两件事件，会导致你工作的复杂度晋升，容易出错。
一般而言，重构会改变程序的设计构造改变相对来说比拟大。然而因为没有性能方面的增加，所以对应的测试案例咱们不须要进行批改，那对咱们来说，只有可能使得现有的重构批改可能满足咱们的业务测试案例就能够了。
增加新性能意味着咱们要增加对应的测试案例，以保障咱们新的性能是可测的。这部分的批改个别会依靠现有的程序结构，改变起来绝对比拟少，并且批改容易甄别。
在绝大多数失常状况下，咱们个别是先增加性能，提交实现当前，再新的批改需要中对代码进行重构。
从大的方向上来说是分两步走的，这两个工作不能一概而论。
一次只做一件事件，一次提交只蕴含一个工作，这是为了防止在工作中人为的减少复杂度，这个复杂度蕴含代码批改，审查，测试等各个方面。
防止复杂度的回升，是咱们在软件开发过程中时刻要谨记的一个准则。
俗话说，一口吃不成瘦子，心急吃不了热豆腐。做事件要一步一个脚印，操之过急，步步为营。
2. 重构的价值和评判成果
问题:
哪种类型的代码重构是高价值的？
1. 在网上跑了这么多年也没啥问题，为什么要动他？
2. 重构前后性能又没啥变动，以后收益是啥？
3. 若是进步可维护性，可扩展性的话，怎么评判成果呢？
回复：
这是对于重构价值和评判后果的问题。
这几个问题问的都很好。
咱们来看第 1 个问题，就是 ” 在网上跑了这么多年也没啥问题，为什么要动 ” 的问题？
这里的关键点就在于到底有没有问题。是不是说在客户那边客户看不到问题，就算是没问题。
当然不是的，在咱们软件开发当中，在交付给客户当前，客户那边看到的是黑盒，他不晓得咱们外部的逻辑存在多少的破绽。
如果咱们的外部逻辑存在很多的破绽。假如偶尔某一天，某个客户发现了一个破绽，它能够通过这一个破绽进入到咱们的零碎外部，这样进入咱们的外部，会产生什么样的情况，咱们能够本人设想。
在公司的外部发言中专门提到了 UK 对咱们产品的一个评估，外层是固若金汤，内层是很软弱的，客户或者黑客一旦进入到咱们的外部当前，他就能够随心所欲了，从这一点上来说，咱们肯定要对咱们现有的代码进行重构，以防止这样的问题。
咱们再来看第 2 个问题。重构前后性能又没啥变动，以后收益是什么？
重构最大的收益是解决如下的问题:
代码太多反复问题，单个函数体或者文件或者攻城过大的问题，模块之间耦合度太高的问题等等。
以上问题归根结底就是一个问题，就是简单度过高的问题。
当初来谈一谈复杂度的问题，软件开发中的复杂度当然是越低越好。个别谈到复杂度，咱们可能想到了各种逻辑上的复杂度，设计上的复杂度，实际上在软件过程中复杂度波及到方方面面，咱们来看一下，具体有哪些方面咱们须要留神复杂度的问题。
第一是命名规定。先举个例子，我定一个变量叫 word。有的人喜爱把它写成 wd。这个就减少了这个变量定义的复杂度，你从 wd 很难明确，这个变量是 word 的意思。
不论是变量的命名还是函数的命名，咱们都心愿看到名字，咱们应该可能了解这个变量或者函数大体是关联到什么样子的事件。
所以审慎的应用缩写是防止命名规定复杂度进步的重要前提。
第二是程序逻辑的复杂度。线性程序执行的复杂度为 1, 呈现分支当前要乘以分支的个数。分支能够是条件判断也能够是循环。所以尽可能的防止分支的呈现是升高程序逻辑复杂度的重要伎俩。
如果程序分支不可避免，要尽可能的把程序分支放到最高的逻辑层。这样做的目标是为了防止在上层解决的时候呈现发散式的分支。发散式的分支会急剧的减少程序的复杂度。
复杂度越高，程序越难保护，复杂度超过肯定水平，人类程序员是无奈解决的。
第三是架构设计的复杂度。架构设计波及到模块设计和零碎设计。要尽可能的把一些专用的模块或者子系统抽取进去，比方平安相干的，日志相干的，工具相干的等等，这些专用的性能可能会被所有其余的业务模块或零碎所调用。
在调用这些专用性能的时候，越简略越好，并且调用者不须要关怀具体的外部实现，只须要晓得如何应用就能够了。
这样做的目标是让程序员专一到业务代码的设计上来。
第四是零碎部署的复杂度。零碎部署蕴含几个不同的阶段如开发阶段，测试阶段和生产阶段。不论是哪个阶段，部署的步骤越少越不容易出错。有些零碎人造的须要很多指令的配置，如果是这样的状况，须要编写一个批处理的文件来简化内部使用者的部署步骤，把多个步骤变成一步。
与部署相关联的还有集成局部。如果可能实现自动化或者从模板中创立那是十分好的状态。
第五是测试的复杂度。测试分白盒测试和黑盒测试。白盒测试的复杂度间接关联着代码层级的复杂度，代码层级的复杂度越高，当然白盒测试的复杂度也就越高。
白盒测试须要留神的一个重要问题是不要使白盒测试这部分的代码脱离实际业务代码的设计。也就是说白盒测试它的附丽对象就是咱们理论的业务代码，从架构设计上说是一个从属层，不要试图在这里应用什么软件设计艺术或者所谓的编程艺术。
这种代码的格调就是简略间接，复杂度线性化。
黑盒测试的复杂度来自于业务需要剖析。要有十分清晰的文档阐明，须要对测试步骤和预期后果写的十分分明。
第六是技术的复杂度。技术的发展趋势个别是越倒退越简略，性能越弱小。那么在设计和开发的过程中，要防止应用老旧的技术。对于技术框架的抉择，要提前做好调研。前端选什么框架，要不要抉择某些 UI 库，后端选什么框架，要不要抉择某些程序库，原则上是为了简化咱们的学习过程，进步开发效率，加强整个我的项目的可维护性。须要具体问题具体分析。
第七是队伍构造的复杂度。队伍形成肯定要短小精悍，人多不肯定好办事。像亚马逊提倡的是两张披萨团队，意思是说整个团队两张 pizza 就能吃饱。大体估算就是 10 人左右的一个队伍。当然这只是一个参考指标。
整个队伍的指标肯定要明确。所有的人都向着那个指标迈进，分工能够不同，然而指标肯定要统一。
指标 + 分工是队伍胜利运作的要害。具体来说就是把指标分成多个工作，每个工作里又能够分成小工作，那所有的人都去做对应的工作，本人让本人忙起来，而不是他人让你忙起来。
咱们当初来看一下第 3 个问题，就是如何评判重构成果的问题。在下面的剖析中，咱们曾经理解了重构的指标和最大的收益，就是复杂度的升高。
那么对应的，就是代码的反复率大大降低了，单个函数体或者代码文件或者工程过大的问题不存在或者缩小了，模块之间的耦合性升高了。
再进一步说，就是对于代码的可维护性和可扩展性上，咱们须要关注这么几点:
一是代码的可读性，咱们看到现有的代码就应该能够了解代码作者的用意是什么，这样咱们在批改 bug 的时候就更容易把握。比方函数，类或者组件的性能要单一化，命名要敌对，要删除一些误导性的正文，对于一些没用的代码，要毫不客气的摈弃。
二是设计模式的可参考性。设计模式的益处就是提供一种能够追寻的代码扩大轨迹，新的性能能够遵循这种轨迹模板进行增加，从而取得复杂度线性增长的成果。
三是白盒测试的欠缺性。只管咱们有十分弱小的测试团队，对于黑盒测试方面有很多的教训和心得，然而当初咱们有很多我的项目不足白盒测试案例，这使得开发者在进行重构的时候，面临十分难堪的地步。没有充沛的白盒测试案例，重构工作会举步维艰，有一种瞎子摸象的感觉。
当初就说一下白盒测试这一部分。测试的框架应该在我的项目开始阶段或者重构开始前搭起来。等局部代码成型的时候，逐渐的增加必要的测试案例。测试案例的选取能够依照环形复杂度的计算方法来确定，也能够依据集成测试对应的用户需要来确定。
与代码相干的测试，个别有单元测试, 集成测试和零碎级的测试。
单元测试，个别被认为十分繁琐。单元测试的繁琐次要体现在测试案例的选取上, 如果应用全笼罩形式来选取测试案例的话，会产生大量的测试代码，当前保护起来也是一个累赘。如果采纳环形复杂度来选取测试案例的话，会产生适量的测试代码，然而环形复杂度的计算也是一个很大的工夫开销。
集成测试 跟客户的理论业务需要相干。在这个过程中须要理清接口的输出与输入，以及运行门路，而后据此来设计测试案例，写出测试案例代码。
开发人员个别不会回绝写集成测试。因为她带来的益处是实实在在的，会极大的进步你的开发效率和调试效率。尤其是对于无界面的程序接口尤为重要。
零碎级测试 是大零碎中子系统之间的集成测试。这个次要蕴含两个方面：
一个方面是有界面的自动化测试，通过这样的测试架构来模仿人类用户的应用过程，同时减少一些随机性的行为，试图可能找出零碎的一些破绽。
另一种是无界面的测试，体现在多个服务零碎之间的调用上或者相似浏览器自动化框架的应用上。
一套残缺的测试零碎，能够帮忙工程师进步开发效率，缩小当前系统维护和重构的老本。
从测试的紧迫性上来说，集成测试最为必要，零碎间的测试有时候应用手工测试通过一些测试工具来代替。单元测试能够有很广大的探讨空间，这部分要具体问题具体分析。
3. 重构的机会
问题：
对于重构机会的说法，正确的是？
增加性能时，重构可能使得将来新增个性时更快捷、更晦涩
在修复谬误时，应该聚焦问题自身，不倡议重构，能够防止引入新的问题
专家 Review 时重构，可能传递教训，改善设计，防止或缩小代码继续腐化
回复：
对于重构的机会问题，当初咱们有三个选项，咱们就别离剖析一下这三个选项。
第 1 个选项是说在增加性能的时候进行重构。这个选项的次要问题就是一个提交蕴含了多个工作。这属于人为的减少工作的复杂度。第 1 个毛病是会减少工作的难度，使得原本能够用工作量 1 解决的问题，变成了工作量 2 和 3。第 2 个毛病是减少了代码审查的难度。原本你的提交中形容的是增加性能，后果发现外面的代码批改大部分与此形容无关。
所以第 1 个选项排除。
第 2 个选项是说在修复谬误的时候应该聚焦问题自身，不倡议重构，以防止引入新的问题。
聚焦是点睛之笔。咱们在做任何事件的时候，都不要遗记初心，集中精力攻克问题，不要分心。
所以第 2 个选项是正确的。
第 3 个选项是说专家在审查代码的时候再重构 。这外面的 最关键问题是专家可能并不理解代码的业务需要和利用场景。他们可能看到代码存在不好的滋味，但在不理解业务场景的状况下，让专家进行重构会带来很大的危险。
所以第 3 个选项也不正确。
4. 如何进行重构？
问题：
如何正确的进行重构？
回复：
上面咱们来看看如何进行重构。
简略的代码重构咱们都比拟相熟，比如说你通过工具就能够做一些整顿，如变量重命名，函数抽取，类创立等等。
当初比拟头疼的一个话题就是对老产品的重构，一些老产品波及到上千万行，上亿行的代码。
对于老产品整改的问题。如果只是缝缝补补的话，可能起不到化繁为简的目标。其实做相似这种工作的话，有一个比拟可行的计划。就是把现有的产品当做一个成型零碎也就是现有运行的产品，不要做大的改变，顶多就是批改 bug。
而后以这些成型的零碎为基准，去写新的零碎。相当于参照一个大的白盒就写一个小的白盒，这样新的小的白盒品质上必定比大的白盒性能上要有劣势。
这样子循序渐进去做的话，就会比拟靠谱。
有敌人会说下面的做法是重写，字面意义上没错的。
实际上不矛盾。区别就是重构的形式应该从下往上还是从上往下。比如说咱们当初大部分的重构都了解为从下往上来做。也就是感觉这个文件外头有坏代码的滋味，而后就改这个文件，这样做是没有问题的。
比方当初有些教练遇到的问题，就是发现上下文不是很清晰，这个代码为什么要这么写？为什么一个文件有 1 万行或者 3 万行，这个前因后果不是很分明。
这个时候可能就须要从整个子模块来进行一个自上而下的剖析。梳理出这个子模块的性能需要是怎么的，须要有多少个公共接口？外部公共接口的实现形式是不是应该像目前这样的？
一个文件可能写成 1 万行或者 3 万行，必定是有肯定历史起因的，绝大水平是因为全局把握的编程能力不够造成的。
像这种状况，如果从这个文件自身去做重构的话，难度十分之大，然而如果从上往下，从模块的整个设计角度来做重构的话，可能就容易一些。
对于这样的硕大无朋，最好的方法就是分而治之。首先要确定零碎的性能逻辑点，针对这些逻辑点，要编排好对应的检测点，也就是说等咱们实现了重构当前，咱们得确保咱们的重构是没有问题的，这些检测点就是做这个的，咱们能够了解成集成类的测试。
这些集成类的测试肯定要确保能够在以后未重构之前的零碎上失常运行。
有了这个设施当前，咱们就能够发展咱们的重构工作。重构的办法有很多，比方采纳比拟好的工具，函数和变量的命名扭转，调用形式的扭转等等。这些是在现有代码的根底上进行的重构。这里咱们重点说一下重写的形式来实现重构。所谓重写呢，就是另外开拓一套代码底座。甚至能够选用不同的编程语言。
这种状况下重构首先要重用已有的业务逻辑，实现针对业务逻辑集成测试 100% 的通过率。
具体不论采纳哪种形式都要 一个模块一个模块的进行推动。验证实现一个是一个，千万不能急于求成，试图一次性的把某些问题搞定。如果呈现很屡次失败，有可能会消磨掉你的自信心。所以肯定要一点一点的往前推动，始终是在提高当中。采纳了这种形式当前，不论以后的零碎有如许的宏大，你只有保持做上来，就肯定可能把重构工作彻底实现。
这个时候须要做的具体步骤能够参考如下:
1. 依据性能需要定义公共接口。
2. 依据公共接口写出测试案例代码。
3. 这个时候能够依照测试驱动开发的理念去填充代码。
4. 代码能够从现有的代码中抽取进去。
5. 在抽取的过程中进行整顿重构。
这样，这个子模块实现当前，就能够尝试去代替现有的子模块，看看能不能在整个零碎中平安的运行。
对于整个零碎来说，咱们又能够分成很多个子模块。而后又能够对各个子模块各个击破，最终实现对整个零碎的重构。
如果一开始对整个零碎进行重构的话，也是能够从自上而下的角度来看的。
比如说开始的时候先把所有的子模块看成一些占位符，假设他们曾经实现他们的接口了。那对于整个零碎来说，它自身就是一个子模块，属于提纲挈领的那个模块。
这个过程，从字面意义上能够了解成重写，实际上，它也是一个重构的过程，因为咱们必定会重用这个零碎自身的一些现有代码和现有的逻辑。
下面咱们是假设零碎在曾经实现的状况下进行的重构，其实重构能够贯通于软件开发的始终。软件开发的首要指标是实现业务逻辑，可能解决客户的问题。这个指标实现当前，咱们就要谋求代码的洁净度，复杂度可能降到最小，以后的技术可能用到最先进。
所以只有有机会，咱们都应该对代码和设计进行重构。
结语
本文针对收到的几个对于重构方面的问题作了答复，侧重点各不一样，心愿可能给存在雷同困惑的敌人们 有所启发。
点击关注，第一工夫理解华为云陈腐技术~