【学习笔记】认识重构和设计模式——步入代码优化的世界(通俗易懂向）

认识重构和设计模式

• • • 欢迎关注我、共勉:star:
  • 认识重构与模式
  • • 一、重构和设计模式的概念
    • 二、重构的两大类型
    • 三、测试驱动和复合重构
    • 四、一些问题和回顾

欢迎关注我、共勉⭐️

⭐️⭐️代码之狐⭐️⭐️
主要内容：

• 时不时更新算法题解，算法与数据结构
• 时不时分享心灵鸡汤，详见杂谈栏
• 目前主要在学Java高级内容（虚拟机、框架什么的），以及很重要的软件工程、重构和设计模式等，会将书中的知识点提炼总结分享

认识重构与模式

好的代码让人赏心悦目，而坏的代码让人“难以下咽”，举步维艰！

一、重构和设计模式的概念

• 重构：重新构建不合理的部分代码，使之更优良（易扩展、易理解、更整洁等），描述如何对现有的代码问题的动态调整
• 设计模式：前人总结的，经过检验的能够达到良好性能的代码模板，描述性能良好的代码的静态结构，对问题提供通用的“答案”
  

在开始码代码之前，如果没有很好的构思每个类如何组织，不考虑以后修改代码的扩展性问题，那么等待开发者的可能就是一个代码泥潭——因此，在经过代码不断修改调整之后，人们发现有些结构在最后的优良的代码中反复出现，经过总结提炼，产生了设计模式的提出。

在合适的环境中，面对特定的问题，使用对应的设计模式，就能获得良好的程序代码！！

但是实际情况和我们的想象一致吗？大多数情况下预先的良好设计能够解决大部分代码“难看”的问题，但是现在更普遍的情况是——面对不断更新的需求和快速开发的节奏，很难“未卜先知”提前完美的使用设计模式支持，而是大多数的设计不足或者设计过度

为了能够更好的优化代码，更好的帮助开发人员迭代出更“完美”的代码，我们需要动态调整代码结构——重构应运而生，它提供了在已有代码的基础上，如何发现代码问题，如何调整代码使之更“好”的一些原理和实践方法，重构不是一蹴而就的，而是持续动态的过程。

重构使得现有的代码能够根据需要，趋向某种模式，实现某种模式，或者去除某种模式（过度设计问题）

二、重构的两大类型

重构是对现有代码的调整，其调整大概可以分为两个方面——代码搬移，代码优化

• 代码搬移：叫功能切分或者更易于理解，这种重构包含：将重复代码提取到父类、将不合理的功能分配给其他类、将类似的类组合等，涉及了代码片段位置的调整，达到了功能复用、结构优化、逻辑更加合理等目的
• 代码优化：针对一些不涉及结构的方面的挑战，小到调整一个变量名称，大到更换一整个功能库（使用另一种实现替换原有的功能）等，它使得代码性能更好，功能内部实现更加明朗

在将需求分析落到实际设计时候，常常会出现不知道如何安排功能，如何设计类之间的交互，需要哪些类？类应该持有什么功能？该暴露哪些接口？接口的返回参数如何解读？…千辛万苦完成了这些令人头大的设计后，以为可以专心写代码了吗？No！

就算不考虑需求更改的可能性，还可能出现原本设计没有考虑好的地方，比如代码重复，接口不适配，命名不规范不合理，两个开发部分重合…总的来说，都是代码结构和代码位置的问题——在多个地方出现相同逻辑实现？低复用，降低可读性、代码不应该属于这个模块？功能切分不合理、降低模块独立性、一个函数内代码臃肿不堪？难理解，不易使用…

如果遇到以上问题，快快使用重构吧！！不要使得你的代码“欠账”啦！！！

三、测试驱动和复合重构

重构不是一蹴而就的，也不是随心所欲的，至少需要保证一点——重构完后，代码还能“跑”！

• 测试驱动重构：在重构前建立单元测试，确保每次重构后、或者重构过程中关键步骤能够通过测试
• 复合重构：从底层着手重构，从下到上重构，确保了上层的修改适应下层的代码

千万不要脑子一热重构完一堆代码，长吁一口气后，点击运行——然后…你懂的！一堆Bug！！！不要盲目自信，而是花一点点时间编写一个简单的测试用例，每次重构一点就测试一遍！

还有一种情况就是从上层开始重构很可能导致牵一发而动全身的后果，你不可能在一次重构里面调整好从上到下整个项目的结构代码，所以别从太复杂，引用了太多其他对象的模块开始…除非你保证不影响其他地方，只优化一些内部代码！

四、一些问题和回顾

1. 预先的模式设计无用？
   • 由于过程中持续重构的优点，以及前期设计的不确定性，似乎所有以更优良代码的目标都可以放到重构中实现？但是，重构仅仅是对代码的调整，为了弥补前期设计的不足——简化前期设计应对灵活变化，避免过度设计，但也不是完全避免前期设计。
   • 预先设计的必要性：快速开始工作，理清需求中的功能划分，严谨的接口消息，以及主要的类等大框架，而且预先设计也属于阶段性的成果，能够快速展示赢得项目信任
2. 重构和设计模式的关系？
   • 重构是过程化的代码调整，设计模式是调整好的一些优秀代码模板——设计模式是重构的目标之一，设计模式提供了一种优良代码的思路，而重构对如何确定代码问题以及如何趋近优良代码提供指导
3. 最常见的重构？
   • 提炼函数：将一个长函数（函数体内代码长度超过10行）的代码进行切分，使得一个长函数变成若干短函数的组合，如果短函数有一定关系，提炼出一个支持类，将短函数下放到支持类——代码搬移
   • 提炼类：调整一系列参数，包装成一个类，提供相应修改访问支持，使得代码中不出现一堆直接暴露的参数而导致调整麻烦和参数过多——代码优化
4. 为什么需要测试，如何测试？
   • 测试是保证每一步重构的正确性，快速判断单个函数功能——单元测试。如果不能快速保证重构正确，全靠重构者自行判断，效率不高，而且很容易出错且不能找出哪一步出错。简单的说测试是重构的保障
   • 单元测试核心就是创建一个实例，调用实例的某个函数，自行传入一个特殊的用例，然后判断其返回结果正确与否——不管怎么说，快去使用JUint试一试吧！

怎么还没人关注我😢