重构-改善既有代码的设计总结

软件开发中的代码重构和优化代码重构和优化在软件开发中扮演着非常重要的角色。

代码重构指的是通过调整代码结构、优化算法、增加注释等手段，提高代码的可读性、可维护性、可扩展性和可重用性，而代码优化则是指通过优化算法、减少资源占用、提高代码执行效率等手段，使得程序更加高效。

代码重构的目的是使得代码更易于理解和维护。

当代码的结构杂乱、设计不合理时，理解代码的逻辑和意图会变得非常困难。

而重构可以通过重组代码结构、提取通用模块、优化命名等方式，使得代码变得更加清晰和易读。

通过重构，不仅可以加快开发效率，还能够降低维护成本。

在进行代码重构时，我们首先需要对代码进行分析和评估。

通过代码静态分析工具和性能分析工具，可以找出代码中的问题和瓶颈，找出需要重构的部分。

同时，对于一些重复的代码块，可以提取到函数或类中，以提高代码的可重用性。

在重构的过程中，我们还需要充分运用面向对象的设计原则，比如单一职责原则、开闭原则、依赖倒置原则等，使得代码更加符合良好的设计原则。

代码优化的目的是提高程序的性能和效率。

在进行代码优化时，我们首先需要对程序进行性能测试和分析，找出性能瓶颈。

然后针对性地进行优化，比如通过改进算法、减少内存消耗、优化数据库查询等手段，提高程序执行的效率和响应速度。

同时，还需要对程序进行多线程、异步等技术的应用，以充分利用计算资源。

代码优化需要综合考虑时间复杂度、空间复杂度、计算资源占用等因素，以达到最佳的优化效果。

代码重构和优化需要在合适的时机进行。

在项目初期，我们应该注重代码的可读性和易扩展性，通过良好的设计和结构，尽量避免代码重构和优化带来的额外工作量。

而在项目后期，随着代码规模的增大和功能的完善，我们可以逐渐进行代码重构和优化，以提高程序的性能和可维护性。

总之，代码重构和优化是软件开发中不可缺少的环节。

通过良好的代码重构和优化，可以提高代码的可读性、可维护性和可扩展性，提高程序的性能和效率，降低项目的维护成本。

重构-改善既有代码的设计：编写代码22宗罪（三）1 Duplicated Code重复代码不同的地方出现相同的程序结构:如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们和而为一，程序会变得更好。

最常见的“重复代码”就是一个类内的两个函数含有相同的表达式。

另一种常见情况就是两个互为兄弟的子类内含有相同的表达式。

1）同一个类的2个函数含有相同的表达式，这时可以采用Extract Method(提炼函数）提炼出重复的代码，然后让这2个地点都调用被提炼出来的那段代码。

2）两个互为兄弟的子类内含相同表达式，只需对2个类都是用Extract Method(提炼函数），然后对被提炼出来的函数是用Pull Up Method （方法上移），将它推入超类。

如果代码之间只是类似，并非完全相同，那么就得运用Extract Method(提炼函数将相似部分和差异部分隔开，构成单独一个的函数。

然后你可能发现可以运用Form Template Method （塑造模板函数）获得一个Template Method设计模式。

如果有些函数以不同的算法做相同的事，你可以选择其中较清晰地一个，并是用Substitute Algorithm （替换算法）将其他函数的算法替换掉。

如果2个毫不相关的类出现重复代码，你应该考虑对其中一个运用Extract Class （提炼类），将重复代码提炼到一个独立类中，然后在另一个类内使用这个新类。

但是，重复代码所在的函数可能只应该属于某个类，另一个类只能调用它，抑或这个函数可能属于第三个类，而另2个类应该引用这第三个类。

你必须决定这个函数放在哪儿最合适，并确保它被安置后就不会再在其他任何地方出现。

函数中的代码行数原则上不要多于100行:我们遵循这样一条原则：每当感觉需要以注释开说明点什么的时候，我们就需要把说明的东西写进一个独立的函数中，并以其用途（而非实现手法）命名。

90%的场合里，要把函数变小，只需使用Extract Method(提炼函数) ，找到函数中适合集中在一起的部分，将它们提炼出来形成新函数。

重构-改善既有代码的设计重构，第一个案例重构原则何为重构1. 名词：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本2. 动词：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构和性能优化形成对比都不改变组件的行为，只改变内部结构目的不同，重构的目的是使软件更容易被理解两顶帽子来回换，但是尽量不同时做添加新功能重构为何重构重构改进软件设计防止程序的设计逐渐腐败变质消除重复，让所有的事物和行为在代码中只表述一次，这正是软件设计的根本重构是软件更容易理解研究理解别人的代码的时候，也可以尝试重构，Ralph Johnson把这种“早期重构”描述为“擦掉窗户上的污垢，使你看得更远”重构帮助找到bug重构能帮助写出更健壮的代码最终，重构提高编程速度何时重构随时随地，不需要专门重构，重构是因为你想做别的什么事，而重构可以帮助你把那些事情做好三次法则第三次做类似的事情，就应该重构添加功能时重构修补错误是重构复审代码时重构重构的难题数据库修改接口难以通过重构的手法完成的改动何时不该重构既有代码太混乱，重构它还不如重新写一个来得简单重构之前，代码必须保证能够在大部分情况下正常运作，否则就重写可以先重构为封装良好的小型组件，然后就可以逐一对组件作出重构或者重建项目已经接近最后期限，避免重构如果最后你没有足够的时间，通常就表示你其实早就该进行重构重构与设计有了设计，我可以更快的思考，但是其中充满小漏洞极限编程的支持者极力支持使用重构取代预先设计，CRC卡重构与性能首先写出可调的软件，然后调整它以求获得足够的速度在性能优化阶段，首先要度量重构起源何处Ward CunninghamKent BeckRalph JohnsonBill OpdykeJohn BrantDon Roberts代码的坏味道重复代码（Duplicated Code）同一个类两个函数互为兄弟的子类只是类似，并非完全相同两个不相干的类出现重复Extract Method, Pull Up Method, Form Template Method, Template Method, Substitute Algorithm, Extract Class过长函数（Long method）间接层所能带来的全部利益--解释能力，共享能力，选择能力--都是由小型函数支持的每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名条件表达式和循环常常也是提炼的信号Extract Method, Replace Temp with Query, Introduce Parameter Object, Preserve Whole Object, Replace Method with Method Object, Decompose Conditional过大的类（Large Class）先确定客户端如何使用它们，然后运用Extract Interface为每一种使用方式提炼出一个接口。

重构，改善既有代码的设计--总结篇重构，改善既有代码的设计--第⼀章感悟⼀、书中经典句⼦1.重构之前，⾸先检查⾃⼰是否有⼀套可靠的测试机制。

这些测试必须有⾃我检验能⼒。

2.⾯对长长的函数，需要分解，代码块越⼩越好管理。

⼆、⾃⼰总结的句⼦1.修改长长的函数，找到变的参数和不变的参数，变的参数保留，不变的参数传⼊新函数。

2.重构的时候使⽤快捷键重构之后，需要检查⽅法⾥⾯的参数，参数如果是不变的值如a=1;，直接在⽅法⾥⾯去定义就⾏了，这样就省去了传值的过程，效率更⾼。

3.在重构函数之后，若函数的参数不属于当前类，并且函数中没使⽤当前类，需要把⽅法移动到参数所属的类去；如：A类⾥⾯的⽅法DoSomething(B b){b.getLabel(){}//do many things}；需要移动到B类中去,4.重构之后需要检查下被重构的函数被多少个地⽅使⽤，保证⽆错5.对于接受⼀个⽅法返回值的参数如var a=B.getA();在这⾥a是完全没有必要的，可以直接把它给删除，在使⽤到a的地⽅替换为B.getA()6.为了使得⽅法看起来更加简洁，可以把⽅法中的变量和使⽤到变量的逻辑给抽取出来，形成⼀个⽅法，删除变量之后再使⽤到变量的地⽅⽤⽅法替代。

7.在switch语句，最好不要在另⼀个对象的基础上运⽤switch语句。

如果不得不使⽤，也应该在对象⾃⼰的数据上使⽤，⽽不是别⼈的数据上使⽤。

⽐如：A类中的⽅法MethodA()中的switch⾥⾯使⽤的都是B类对象引⽤的数据如：case B.NUMBER;则需要把该⽅法转移到B类中去，以减少没必要的引⽤。

重构，改善既有代码的设计--第⼆章感悟⼀、摘取章句1.改进设计的重要⽅向是消除重复代码。

2.⼒求代码容易理解3.早起重构被描述为“擦掉窗户上的污垢，使你看得更远。

”⼆、何时重构1.在给软件添加功能的时候重构2.修补错误时候重构：在重构中来找出系统的bug3.复审代码时候重构4.个⼈觉得在功能完成之后顺便重构会更好，因为在那个时候对代码还是很熟悉，还有可以在重构的时候去发现开发过程中遗留下来的bug重构，改善既有代码的设计--第四章感悟1.类应该包含它们的测试代码。

一提词器文档如何改善代码的设计- 读《重构》这本书在五年前读了一次，当时读完觉得自己的水平上了一个台阶，然后开始在生产项目中实践。

当时的项目是一堆没人维护的遗留代码，每当要做个新功能时，我都会重构（更准确的说法是重写）下与新功能相关的逻辑，因为没有测试用例的支撑，经常会因为改出问题导致自己加班。

当时我从这种修改代码的过程中找到了编程的乐趣，那是一种畅快淋漓的感觉，重构后的代码似乎也成了体现我个人编程水平的象征。

随着写的代码越来越多，维护项目中的这些代码耗费了我太多的时间，想写新的功能时发现自己无法抽身出来。

我渐渐地感觉到代码成了一种负债，写的越多负债越多，我被自己的写的代码给困住了。

近期重读《重构》这本书，深感以前的我在重构方面至少犯了三个错误。

1重构前没写单元测试。

这样的重构很容易给自己挖坑，本想改个函数名，结果却捅了个蚂蜂窝。

每次重构都觉得不踏实，生怕改错了什么地方2添加新特性和重构同时进行，最后一起测试。

这样容易搞混原有功能与新特性。

一起测试意味着没有单独对重构的代码进行小范围的测试，让代码集成测试起来复杂3为了重构而重构。

很多时候重构成了一种强迫症，还美其名曰说自己有代码洁癖代码不仅仅是写完就好了，还需要维护。

维护说白了就是让代容易理解，让代码易于扩展修改成本低。

容易理解的代码可以很方便的交接出去给其它同事维护，难理解的代码就只能砸在自己手里。

一旦有缺陷或者新功能，修改成本低易扩展的代码可以让你很快就完成需求，收获同事的佩服，早点下班。

让代码易于维护就得借助重构来完成。

近些年在项目中逐渐被“剥夺”了写代码的权利，看代码和定位问题的时间超过了写代码，从工作中得到的乐趣少了很多。

希望重拾重构，从编程中找回那久违的畅快淋漓。

摘录关于重构1什么是重构？○不改变软件可观察行为的前提下，提高可理解，降低软件维护成本2为什么重构？○可以改进软件设计。

代码被阅读和被修改的次数远远多于它被编写的次数○可以使软件更容易理解。

重构改善既有代码的设计最近接⼿⼀个项⽬，源代码的架构和许多设计都有坏的味道。

想要重构，但是⾃⼰并没有⾜够的底⽓.⼀、重构的纠结：(1)现有代码可⽤，你重构后是否会⽐现在更有效率；(2)项⽬进度⽐较紧，你是否要抽出时间做这种没有KPI的⼯作；(3)你重构后，别⼈需要重新阅读你的源代码，给同事带来了重新学习代码的⼯作量；(4)项⽬是否能够持续，如果没有需求，不⽤了，你还重构什么？(5)你是否要在这个公司待很久，等重构完后，你可能都不在了。

⼆、如果不重构，确实会给开发带来很⼤困难：原代码就像是⼀个打满了补丁的棉袄，它可以保暖，但是很难定位到哪⾥漏风，即使定位到了，不过是新打些补丁，但是缝缝补补的⼯作可能没有尽头。

(1)修改很耗精⼒；(2)BUG花样迭出(3)扩展性差，持续开发跟进需求很难；(4)应变能⼒差，牵⼀发动全⾝。

重构或不重构，这是个问题，直到看了《重构改善既有代码的设计》，给了我很⼤启发。

粗略看了⼀遍，道理明⽩了⼀些，我之前的想法应该叫做重写⽽不是重构。

重构是逐步改善的过程，是重写与打补丁的中间选项。

当然看完书之后，我还是选择了重写，因为项⽬还不是很⼤，重写做起来⼯作量更⼩⼀些。

重构的核⼼还是使代码尽量遵循设计模式的六⼤原则：（1）单⼀职责原则（2）⾥⽒替换原则（3）依赖倒置原则（4）接⼝隔离原则（5）迪⽶特法则（6）开闭原则重构中⽤到的⽅法，是写代码过程中很好的参照。

⽅法都写在2-13章的⽬录⾥了，意思⽐较明显，闲来的时候看看，也⼤有裨益。

第2章重构原则2.1何谓重构532.2为何重构552.3何时重构572.4怎么对经理说602.5重构的难题622.6重构与设计662.7重构与性能692.8重构起源何处71第3章代码的坏味道3.1 DuplicatedCode（重复代码）763.2 LongMethod（过长函数）763.3 LargeClass（过⼤的类）783.4 LongParameterList（过长参数列）783.5 DivergentChange（发散式变化）793.6 ShotgunSurgery（霰弹式修改）803.7 FeatureEnvy（依恋情结）803.8 DataClumps（数据泥团）813.9 PrimitiveObsession（基本类型偏执）813.10 SwitchStatements（switch惊悚现⾝）823.11 ParallelInheritanceHierarchies（平⾏继承体系）833.12 LazyClass（冗赘类）833.13 SpeculativeGenerality（夸夸其谈未来性）833.14 TemporaryField（令⼈迷惑的暂时字段）843.15 MessageChains（过度耦合的消息链）843.16 MiddleMan（中间⼈）853.17 InappropriateIntimacy（狎昵关系）853.18 AlternativeClasseswithDifferentInterfaces（异曲同⼯的类）853.19 IncompleteLibraryClass（不完美的库类）863.20 DataClass（纯稚的数据类）863.21 RefusedBequest（被拒绝的遗赠）873.22 Comments（过多的注释）87第4章构筑测试体系4.1⾃测试代码的价值894.2 JUnit测试框架914.3添加更多测试97第5章重构列表5.1重构的记录格式1035.2寻找引⽤点1055.3这些重构⼿法有多成熟106第6章重新组织函数6.1 ExtractMethod（提炼函数）1106.2 InlineMethod（内联函数）1176.3 InlineTemp（内联临时变量）1196.4 ReplaceTempwithQuery（以查询取代临时变量）1206.5 IntroduceExplainingVariable（引⼊解释性变量）1246.6 SplitTemporaryVariable（分解临时变量）1286.7 RemoveAssignmentstoParameters（移除对参数的赋值）1316.8 ReplaceMethodwithMethodObject（以函数对象取代函数）1356.9 SubstituteAlgorithm（替换算法）139第7章在对象之间搬移特性7.1 MoveMethod（搬移函数）1427.2 MoveField（搬移字段）1467.3 ExtractClass（提炼类）1497.4 InlineClass（将类内联化）1547.5 HideDelegate（隐藏“委托关系”）1577.6 RemoveMiddleMan（移除中间⼈）1607.7 IntroduceForeignMethod（引⼊外加函数）1627.8 IntroduceLocalExtension（引⼊本地扩展）164第8章重新组织数据8.1 SelfEncapsulateField（⾃封装字段）1718.2 ReplaceDataValuewithObject（以对象取代数据值）1758.3 ChangeValuetoReference（将值对象改为引⽤对象）1798.4 ChangeReferencetoValue（将引⽤对象改为值对象）1838.5 ReplaceArraywithObject（以对象取代数组）1868.6 DuplicateObservedData（复制“被监视数据”）1898.7 ChangeUnidirectionalAssociationtoBidirectional（将单向关联改为双向关联）197 8.8 ChangeBidirectionalAssociationtoUnidirectional（将双向关联改为单向关联）200 8.9 ReplaceMagicNumberwithSymbolicConstant（以字⾯常量取代魔法数）2048.10 EncapsulateField（封装字段）2068.11 EncapsulateCollection（封装集合）2088.12 ReplaceRecordwithDataClass（以数据类取代记录）2178.13 ReplaceTypeCodewithClass（以类取代类型码）2188.14 ReplaceTypeCodewithSubclasses（以⼦类取代类型码）2238.15 ReplaceTypeCodewithState/Strategy（以State/Strategy取代类型码）2278.16 ReplaceSubclasswithFields（以字段取代⼦类）232第9章简化条件表达式9.1 DecomposeConditional（分解条件表达式）2389.2 ConsolidateConditionalExpression（合并条件表达式）2409.3 ConsolidateDuplicateConditionalFragments（合并重复的条件⽚段）2439.4 RemoveControlFlag（移除控制标记）2459.5 ReplaceNestedConditionalwithGuardClauses（以卫语句取代嵌套条件表达式）250 9.6 ReplaceConditionalwithPolymorphism（以多态取代条件表达式）2559.7 IntroduceNullObject（引⼊Null对象）2609.8 IntroduceAssertion（引⼊断⾔）267第10章简化函数调⽤10.1 RenameMethod（函数改名）27310.2 AddParameter（添加参数）27510.3 RemoveParameter（移除参数）27710.4 SeparateQueryfromModifier（将查询函数和修改函数分离）27910.5 ParameterizeMethod（令函数携带参数）28310.6 ReplaceParameterwithExplicitMethods（以明确函数取代参数）28510.7 PreserveWholeObject（保持对象完整）28810.8 ReplaceParameterwithMethods（以函数取代参数）29210.9 IntroduceParameterObject（引⼊参数对象）29510.10 RemoveSettingMethod（移除设值函数）30010.11 HideMethod（隐藏函数）30310.12 ReplaceConstructorwithFactoryMethod（以⼯⼚函数取代构造函数）30410.13 EncapsulateDowncast（封装向下转型）30810.14 ReplaceErrorCodewithException（以异常取代错误码）31010.15 ReplaceExceptionwithTest（以测试取代异常）315第11章处理概括关系11.1 PullUpField（字段上移）32011.2 PullUpMethod（函数上移）32211.3 PullUpConstructorBody（构造函数本体上移）32511.4 PushDownMethod（函数下移）32811.5 PushDownField（字段下移）32911.6 ExtractSubclass（提炼⼦类）33011.7 Extract Superclass (提炼超类) 33611.8 Extract Interface (提炼接⼝) 34111.9 Collapse Hierarchy （折叠继承体系）34411.10 FormTemplateMethod（塑造模板函数）34511.11 Replace Inheritance with Delegation（以委托取代继承）35211.12 Replace Delegation with Inheritance （以继承取代委托）355第12章⼤型重构12.1 Tease Apart Inheritance （梳理并分解继承体系）36212.2 Convert Procedural Design to Objects （将过程化设计转化为对象设计）368 12.3 Separate Domain from Presentation （将领域和表述/显⽰分离）37012.4 Extract Hierarchy （提炼继承体系）375。

代码重构与优化改善既有代码的质量与可读性代码重构与优化：改善既有代码的质量与可读性代码重构与优化是软件开发过程中非常重要的环节，它旨在改善既有代码的质量和可读性，从而提高软件的可维护性和可扩展性。

本文将探讨代码重构与优化的概念、目的、方法以及效益等方面内容，帮助读者更好地理解并应用于实际开发中。

一、概念和目的代码重构是指在不改变代码外在行为的情况下，通过调整代码内部结构，使得代码更易于理解、修改和扩展的过程。

它是一种对代码进行有目标性的修改的过程，以消除代码中的重复、提取通用的模块或函数、简化复杂的逻辑结构等方式来改进代码质量。

而代码优化则是为了提高代码的执行效率而进行的修改，以减少程序运行的时间或空间消耗。

代码重构与优化的目的在于改善代码的可维护性、可读性和可扩展性。

良好的代码结构和清晰的代码逻辑能够使得代码更易于理解和修改，减少出错的可能性。

而对于代码的优化，则可以提高程序的执行效率，降低系统资源的占用，提升用户体验。

二、常用的代码重构技术1. 提取函数：将重复的代码块提取成函数，减少代码冗余。

2. 合并函数：将功能相似的函数合并成一个，减少函数数量和复杂度。

3. 重命名变量和函数：使用有意义的命名，提高代码的可读性。

4. 删除冗余代码：删除未使用的变量、函数和注释等冗余代码，减少代码的臃肿。

5. 拆分长函数：将过长的函数拆分成多个小函数，提高代码的可读性和可维护性。

6. 消除魔术数字：将代码中的魔术数字提取为常量或变量，增加代码的可维护性。

7. 使用设计模式：应用合适的设计模式来改善代码结构，提高代码的可读性和可扩展性。

8. 更新注释：及时更新代码注释，保持代码文档的准确性和完整性。

三、代码优化的常用策略1. 选择合适的数据结构和算法：根据具体问题的特点，选择最合适的数据结构和算法，以提高程序的运行效率。

2. 减少循环的次数和嵌套层次：避免不必要的循环和嵌套，以减少程序执行的时间消耗。

3. 使用缓存：对频繁访问的变量或计算结果进行缓存，减少系统资源的占用。

《重构—改善既有代码设计》——第⼆章重构原则——学习笔记1：什么是重构？重构是⼀个过程：在不改变代码外在⾏为的前提下，对代码做出修改，以改进程序内部结构。

本质上说，重构就是【在代码写好之后改进它的设计】2：为什么要对项⽬进⾏重构呢？重构对软件开发有什么好处，为什么要重构呢，打个贴切的⽐⽅：我平时⽐较懒散，屋⼦⾥⾯的东西都是随⼿乱放，时间长了，屋⼦⾥⾯就乱七⼋糟了。

有时候到了⾃⼰也忍⽆可忍的时候，我就要⼤动⼲⼽了，把该放哪⼉的东西都整理到哪⼉，该扔掉的东西全部扔掉。

⼀个项⽬也是如此，有时候可能是设计不到位；有时候可能是经过多⼈的修改，代码凌乱不堪；甚⾄有些地⽅都是在堆砌代码；可能有些新⼿写的代码或是⾃⼰以前写的代码，让你看不下去了…。

于是你挥动⼤斧对项⽬进⾏劈砍⼀番。

重构的好处⽤⾃⼰的话简单的概括为: 改善软件设计、提⾼代码质量、提⾼程序可读性、减少错误、使以后功能扩展更容易。

【重构改进软件设计】⼤家可能都有亲⾝体会，⼀个项⽬的代码质量往往有可能会随着时间的推移变得越来糟糕，代码愈来愈雍窘，越来越难以理解它的本意。

添加新功能越来越难。

这⾥⾯的原因是多⽅⾯的，重构可以减少代码量，使以后的维护，开发更⽅便【重构使软件更容易理解】重构整理过后的代码，确实让你更容易理解【重构有助于你找到BUG】重构的时候，你必须去阅读代码，分析、理解逻辑，这样你就很可能发现⼀些逻辑或是简单的错误。

⽽且重构的时候都要做⼀些必须的测试，也是有助于找到⼀些潜藏的错误的。

【重构有助于提⾼你的编程速度】这个没有亲⾝体验过的⼈，估计只有⼀个形象的感受。

我曾经参与到⼀个项⽬⾥⾯，那个项⽬简直到了你恨不得推翻它重写的地步。

函数雍窘超长；代码到处堆砌；没⽤分层；逻辑耦合；通篇没啥注释。

有时候你为了了解这个函数的功能，都要花费⼤量的时间和功夫。

⽤同事的话说：“对这些代码望⽽⽣畏”。

你想这样⼀个代码质量低劣的项⽬，做功能扩展、维护不拖累你的编程速度才怪。

学习代码重构的实践与经验总结代码重构是指对已经存在的代码进行修改、优化、重组，目的是改善代码的质量、可维护性、可读性、性能等方面的问题。

重构的目标是提高代码的可理解性、可维护性以及重用性，减少代码的复杂度。

以下是关于代码重构的实践与经验总结。

一、了解重构的原则和目标在进行代码重构之前，需要先了解重构的原则和目标。

Martin Fowler在其著作《重构：改善既有代码的设计》中提出了许多重要的原则和目标，如坚持“小步快跑”原则、按照“以小代大”原则进行重构、保持代码可读性、保持代码功能不变等。

了解这些原则和目标有助于我们进行更加有效的代码重构。

二、建立测试案例在进行代码重构之前，需要先建立良好的测试案例。

这些测试案例可以帮助我们在重构过程中确保代码的正确性。

在重构之前，我们可以运行这些测试案例，然后在重构之后再次运行这些测试案例，以确保代码的行为没有发生改变。

三、重构的过程代码重构的过程可以分为以下几个步骤：1.确定重构的目标：先确定要解决的问题和目标，比如提高代码的可读性、可维护性等。

2.找出要修改的代码区域：通过代码审查、调试和分析来找出需要修改的代码区域。

3.小步重构：按照“小步快跑”的原则进行重构，每次只修改一小部分代码。

修改完成后运行测试案例，确保代码行为没有发生改变。

4.提交代码：当重构的过程完成后，提交代码并进行自动化构建和测试。

四、常见的重构技术以下是几种常见的代码重构技术：1.提取方法：将一段功能相似的代码提取为一个独立的方法，以提高代码的可读性和重用性。

2.内联方法：将一个只被调用一次的方法内联到调用处，减少不必要的方法调用开销。

3.提取变量：将一个复杂的表达式提取为一个变量，以提高代码的可读性和可维护性。

4.移动方法：将一个方法从一个类移到另一个类，以提高代码的组织性和可重用性。

5.对象封装：通过封装实现对对象的访问控制，以增加代码的模块性和可维护性。

6.消除过长的参数列表：将多个参数封装为一个对象，以减少参数个数和提高代码的可读性。

《重构：改善既有代码的设计》读书笔记第三章第三章代码的坏味道3.1 神秘命名命名是编程中很难的事情，所以最常⽤的重构⼿段就是去改个名字。

如果你发现改名很难，那就说明代码设计有问题。

3.2 重复代码同⼀类的两个函数含有相同的表达式，就应该提炼。

3.3 过长函数活得最长，最好的函数，⼀般都很短。

如果你觉得需要写注释，⼤部分情况就代表这个东西需要写进⼀个独⽴的函数⾥⾯，然后根据⽤途来命名⽐较好。

3.4 过长的参数列表将⼏个函数共⽤的参数抽象成类，然后再调⽤类。

3.5 全局数据全局数据的问题是，全局数据在任何地⽅都可以被修改。

所以正确的做法是将全局数据封装起来，⽤函数将其包起来，这样就知道那些地⽅修改了它。

3.6 可变数据核⼼是缩⼩作⽤域。

3.7 发散式变化如果这个模块，加不同原因的需求的时候，修改的模块都不相同的话，你需要考虑是否要分离出来。

⽐如说你加⼊redis需要改3个地⽅，加⼊mysql需要改4个地⽅，你就应该抽离出来。

3.8 霰弹式修改在每次修改的时候，应该只修改⼀处，⽽不是到处的修改。

如果你说你要加⼊⼀个数据库，需要修改3个函数，那么这就需要思考，你是否应该抽离出来。

3.9 依恋情结模块化，⼒求代码分出区域，最⼤化区域内部交互，最⼩化区域间交互。

如果两个模块交互频繁，你应该合并在⼀起。

3.10 数据泥团如果在多个类中，出现了很多相同项的数据，你需要想想是否要抽离出来⼀个对象。

3.11 基本类型偏执我们应该创建对象，⽽不是⽤⼀个字符串来写任何东西。

⽐如有程序员⽤字符串来表⽰电话号码，实际上你应该抽象出来⼀个电话号码对象。

3.12 重复的switchswitch这个东西就不应该存在。

3.13 循环语句我们应该⽤管道操作来替代循环，这样能更看清被处理的元素和处理他们的动作。

3.14 冗赘的元素能简单的代码，尽量简单。

未来变复杂的时候，再去考虑它。

3.15 夸夸其谈通⽤型同上。

3.16 临时字段临时的字段不应该存在。