重构

文章目录 前言 时空变换之空域优化 逻辑化简 资源合并 模块复用之分时复用 静态重构 动态重构 思路转换 前言 这是三月的第二篇博客，不得不说的是，有点儿怀念在实验室学习写博客的感觉（当然，并不怀念项目缠身，整日被催进度的噩梦日子），两个大屏幕，一台换了固态硬盘，因此还算流畅的台式电脑，简直不要太爽。平日里最讨厌用笔记本电脑，是因为觉得笔记本的键盘和鼠标很不人性化，这下好了，关键时期，笔记本成为了最依赖的东西，用笔记本打字也顺畅了，都是惯得。哈。当然最重要的还是学习氛围，在家是容易懒惰的，我宁愿打打游戏度日，也不愿坐在桌子前去思考一些复杂的问题，这是大脑惰性的选择。 好啦，这些日子也只能想想啦，也许这样的日子，哪怕一天也不会再有啦，我总是顾虑的，考虑到最坏的情况，疫情结束恐怕还是遥遥无期，毕竟学校不是一个随便开玩笑的地方，人口大量聚集，一起上课，一起吃饭，集体宿舍，这都给传染病提供了最好的传染途径，因此，疫情不结束，恐怕难以开学，更何况开学之后还有很多事情要处理，要么关乎毕业，要么。。。 进入正题，上篇博客是关于时域优化的内容， 回忆一下吧。 时域优化也就是对时序上的问题进行优化，例如我想更快的时钟去处理事件，而更快的时钟要求更精进的设计以及硬件条件要跟得上，假设硬件条件（FPGA）能跟得上，那么剩下的问题就是设计的问题了。 设计的问题，包括冗余的问题，这就需要对逻辑表达式进行化简

在 CodeInsight 开发告一段落之后，CTO 大人找到我说要想一个把 Coding.net 的前端拆分重构的方案，于是我从一个欢脱的开发状态开始切换到要面对一句魔咒的考验。 动态语言一时爽，代码重构火葬场。 不管怎么样，先从梳理现状开始。 Coding 前端使用 Angular 构建，前端工程化还是使用合并文件打包的方式，并没有引入 CommonJS 之类的模块化开发方式，作为一个 SPA 网站，随着网站规模的增大，前端代码开始越来越臃肿，开发体验也直线下降，这是我们考虑重构的原因。 所以首先我们要想清楚重构要解决的问题 代码打包拆分，避免所有功能模块打包到单一的文件 引入 CommonJS 做到更清晰的模块化 边开车边换轮子 要做到最后一点尤其困难，但这也是我们能否顺利重构的关键，重构不是重写，所以如何在现有代码基础上重构，并且还要和当前的开发进度无缝衔接起来就是我们所要面临的一个挑战。 好消息是我们使用了 Angular 保证了我们的代码分 Module 有了一层封装，不至于太过散乱。作为一个 SPA 网站，前端路由已经很好的分离出了各个功能模块。我们用到了 Grunt，虽然有点过时，task 写得有点复杂，但是提供了一个工程化的切入口。 经过小伙伴们几轮讨论之后，最终确定了一套比较靠谱的方案： 按照功能模块重新整理／拆分代码 保持作为一个 SPA 网站

将与业务无关的封装到类库中，可以重复使用 我的Module类库结构图： activity包中存放的是与业务无关的Activity基类。 可以将基类BaseActivity封装到类库里，这里是与业务无关的公用逻辑，主项目中再建立一个AppBaseActivity基类， 封装的是业务相关的公用逻辑， 继承BaseActivity。 net包存放的是网络底层封装 cache包里存放的是缓存数据和图片的相关处理 ui包中存放的是自定义控件 utils包中存放的是各种与业务无关的公用方法，比如对SharedPreferences的封装。 我的app结构图： activity： 可以继续按照模块拆分 adapter：所有适配器都放在这里 db：SQLite相关逻辑的封装 engine：将业务相关的类都封装在一起 entity：将所有实体类都放在一起 interfaces：接口都放在这里，以I开头 listener：基于Listener的接口，命名以On开头 ui：自定义控件 utils：所有给你公用方法 划分的主要目的： 每个文件只有一个单独的类，不要有嵌套。 将Activity拆分模块后，可以迅速定位具体的某一个页面。 使用fastJSON和GSON对数据源获取进行处理：要比每次从JSONObject里通过key取值更方便（但是得根据实际的服务端反馈数据处理，有些数据就是那么一坨一坨

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下。提高其可理解性，降低维护成本。 重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整期结构 重构的优点： 改进软件设计 使软件更容易理解 帮助找到bug 提高编程速度 重构应该随时随地进行，事不过三，三则重构： 添加功能时重构 修补错误时重构 复审代码时重构 重构的难题： 数据库：经常会遇到数据库与应用紧耦合，非面向对象型数据库可以添加分隔层，如使用Hibernate之类的ORM框架；面向对象型数据库 修改接口：对于已发布接口修改是，应保留老接口，是老接口调用新接口，尽量减少发布接口 一个项目开始时候应该考虑好各个模块的灵活性，但实现这种灵活性往往会需要花更多时间，并增加代码的复杂度，同时并不是所有模块的灵活性都有用，所以在时间有限时考虑好通过重构将代码变得灵活的难度，如果不难可以先做非灵活实现，当有需要时在重构。 重构和性能： 重构是代码更易于维护理解的同时，往往会牺牲性能。如果在一个性能要求极高的系统中，应该以性能为优先；对于大多数程序进行分析，会发现它吧大半时间都耗费在一小半代码上，一视同仁的性能优化，90%的努力都是收效甚微的，所以这时可以考虑，这90%的代码用重构获得代码的可读性优先。 代码的坏味道 Duplicated Code（重复代码）：Extract

如果你认为这是一个标题党，那么我真诚的恳请你耐心的把文章的第一部分读完，然后再下结论。如果你认为能够戳中您的G点，那么请随手点个赞。 把三千行代码重构为15行 那年我刚毕业，进了现在这个公司。公司是搞数据中心环境监控的，里面充斥着嵌入式、精密空调、总线、RFID的概念，我一个都不懂。还好，公司之前用Delphi写的老客户端因为太慢，然后就搞了个Webform的替代，恰好我对Asp.Net还算了解，我对业务的不了解并不妨碍我称成为这个公司的一个程序员。小公司也有小公司的好，人少，进去很快负责代码开发。我当然也就搞这个数据中心智能管理系统啦。 这个系统非常的庞大，尤其牛逼的是支持客户端组态，然后动态生成网页，数据还能通过Socket实时监控(那时我还真就不懂网络编程)。这个对于当时的我来说，真真是 高、大、上 呐！！当时跟着了解整个系统大半个月才算能够调试，写一些简单的页面。 在维护系统的过程中，时不时要扩展一些功能，也就接触了下面这个类： 图片有压缩，点击这里查看清晰的原图。 看到没有，就是当年最最流行的三层架构的产物，对于刚出茅庐的毛头小子来说，这是多么专业的文件头注释，还有反射也就算了，这构造函数还能静态的，还能私有的？那时刚接触这么高大上的代码的我，瞬间给跪了！ 但是，类写多了，我就感觉越来越别扭，就是下面这段代码： 图片有压缩，点击这里查看清晰的原图。 每增加一个表

书籍信息 书名：《重构：改善既有代码的设计》 原作名：Refactoring: Improving the Design of Existing Code 作者： Martin Fowler 豆瓣评分：9分(1796人评价) 内容简介 重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码。多年前，正是本书原版的出版，使重构终于从编程高手们的小圈子走出，成为众多普通程序员日常开发工作中不可或缺的一部分。本书也因此成为与《设计模式》齐名的经典著作，被译为中、德、俄、日等众多语言，在世界范围内畅销不衰。 本书凝聚了软件开发社区专家多年摸索而获得的宝贵经验，拥有不因时光流逝而磨灭的价值。今天，无论是重构本身，业界对重构的理解，还是开发工具对重构的支持力度，都与本书最初出版时不可同日而语，但书中所蕴涵的意味和精华，依然值得反复咀嚼，而且往往能够常读常新。 作者简介 Martin Fowler 世界软件开发大师，在面向对象分析设计、UML、模式、XP和重构等领域都有卓越贡献，现为著名软件开发咨询公司ThoughtWorks的首席科学家。他的多部著作《分析模式》、《UML精粹》和《企业应用架构模式》等都已经成为脍炙人口的经典。 Kent Beck 软件开发方法学的泰斗，极限编程的创始人。他是Three Rivers Institute公司总裁，也是Agitar

正交性（orthogonality） 表示某种不相依赖性或者解耦性。如果两个或者更多事物种的一个发生变化，不会影响其他事物。这些事物就是正交的。在设计良好的系统中，数据库代码与用户界面是正交的：你可以改变界面，而不影响数据库，或者更换数据库，而不用改变界面。 如果修改代码中的现存行为只需要到一个地方修改，即拥有正交性。 开放/闭合 原则（OCP，Open Closed Principle） 对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。 对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。 实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的； 而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路。 要获取更多Jerry的原创文章，请关注公众号"汪子熙": 来源： https://www.cnblogs.com/sap-jerry/p/12371441.html

实习一星期了，最近效率有点低，随便写点东西也算是督促下自己吧。 代码重构先留着放到后面了，先把作业进度赶上。 今日踩坑：BehaviorTree 节点间传值，SharedGameObjective 和 GameObject 搞混了，浪费了很多时间。 今日进度：简单学习了下BehaviorTree和NavMesh，关卡设计进度 20% 画饼部分： 　　明日计划：先听课，后面把作业做完，明晚为止最好作业进度能到60%+ 　　需要学的东西 （目前）：FSM状态机，BehaviorTree行为树，NavMesh自动寻路。 　　TODOlist： 　　　　1、作业完成 　　　　2、代码重构 　　　　3、毕设的开题报告 总结：在做了，在做了（进度0%）.jpg 来源： https://www.cnblogs.com/cjbiantai/p/12368343.html

背景 ：函数上千行代码，类巨大，高耦合。业务发展到一定阶段，原来的程序设计不能满足业务需求，或者经过多遍更改后，存在大量冗余的逻辑代码；新的架构设计，进行业务拆分。 重构是在不改变项目现有的业务逻辑或者代码逻辑的基础上对程序进一步提炼或者扩展，使其结构化，代码规范化，弱耦合。非常重要的一点。 糟糕的类型： 1）重复代码； 2）过长的函数（一般超过200行），需要积极的拆分子函数； 3）过大的类，类越大，职责就越多，导致类产生的实例也会越多。同时，职责越多的类，其修改后影响也就越大。 4）过长的参数列表，如果参数过多，或者变化太过频繁，考虑用对象替换参数列表； 5）发散式变化，如果类经常在不同的方向上发生变化，考虑将类拆分。 6）散弹式修改，与发散式变化刚好相反，如果遇到某种变化要修改很多地方，可以考虑将变化的抽到同一个类中。 7）依恋情结，就是如果某个函数功能需要调用另一个类中的大半变化，可以考虑将这个函数抽到变化的类中。 8）数据泥团，数据项总是喜欢成群结队的聚在一起，可以考虑对数据项抽象对象。 9）平行继承体系，就是为某个类增加一个子类的时候，也必须为另一个类增加子类，这时候可以考虑让一个继承体系引用另一个继承体系。 10）冗赘类 11）夸夸其谈的未来性，就是设计的时候过多考虑未来，导致现有的类设计复杂 12）过度耦合的消息链。 I. 小步前进，频繁测试 1）重新提炼函数

1. Duplicated Code( 重复的代码) 臭味行列中首当其冲的就是Duplicated Code。如果你在一个以上的地点看到相同的程序结构，那么当可肯定：设法将它们合而为一，程序会变得更好。 最单纯的Duplicated Code就是［同一个class内的两个函数含有相同表达式(expression)］。这时候你需要做的就是采用Extract Method提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。 另一种常见情况就是[两个互为兄弟(sibling)的subclasses内含有相同表达式]。要避免这种情况，只需要对两个classes都使用Extract Method，然后再对被提炼出的代码使用Pull Up Method，将它推入superclass内。如果代码之间只是类似，并非完全相同，那么就得运用Extract Method将相似部分和差异部分割开，构成单独一个函数。然后你可能发现或许可以运用Form Template Method获得一个Template Method设计模式。如果有些函数以不同的算法做相同的事，你可以择定其中较清晰的一个，并使用Substitute Algorithm将其它函数的算法替换掉。 如果两个毫不相关的classes内出现Duplicated Code，你应该考虑对其中一个使用Extract Class