重构

《重构:改善既有代码的设计》-学习笔记二(+实战解析)

匿名 (未验证) 提交于 2019-12-02 21:53:52
我不是个伟大的程序员;我只是个有着一些优秀习惯的好程序员而己 本人比较直接,不说虚的,直接上干货。 Ŀ¼   Long Parameter List(过长参数列)   Divergent Change(发散式变化)   Shotgun Surgery(散弹式修改)   Feature Envy(依恋情结)   Data Clumps(数据泥团)   Primitive Obsession(基本型别偏执)   Switch Statements(switch惊悚现身) Long Parameter List(过长参数列) 上一节有提过,当函数的入参过多时,可以用第三招,参数对象化,把参数封装成对象,然后参数对象当成函数的入参,达到减少参数的作用。 除了参数对象化,还可以使用另一种方法来处理。 这种方法叫做:Replace Parameter with Method(以函数取代参数) 优化思路: 前提,这个参数是只被赋值一次的 1、如果有必要,将参数的计算过程提炼到一个独立函数中。 2、将函数内有使用参数的地方替换成独立函数。 3、每次替换后,测试。 4、全部替换完成后,最后把这个参数删除。 eg:未优化的代码 public double getPrice() { int basePrice = _quantity * _itemPrice; int discountLevel; if

单元测试

限于喜欢 提交于 2019-12-02 19:49:03
单元测试的目的是测试代码块儿的运行逻辑是对的。 之所以有单元测试,是为了服务重构。 同样,重构是指的改变代码块儿的逻辑但不改变行为。 来源: https://www.cnblogs.com/-outman/p/11761446.html

一个模块反复重构多次的原因有哪些

[亡魂溺海] 提交于 2019-12-02 19:13:29
外因: 1. 需求复杂 2. 需求反复 3. 公共模块缺不够底层 内因: 1. 每次重构没有形成足够的沉淀. 没有分清底层和上层逻辑 2. 对需求发展评估不足 3. 重构不彻底. 模块壁不够清晰. 名存实亡. 留有一些尾巴被后续逻辑利用. 4. 重构周期内被污染 5. 伪重构: 重构重心在分割代码而非抽象 6. 来源: https://www.cnblogs.com/wmalloc/p/11759826.html

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

吃可爱长大的小学妹 提交于 2019-12-02 15:28:59
1 Add Parameter(添加参数) 为此函数添加一个对象参数,让该对象带进函数所需要的信息 注意: 检查函数签名是否被超类or子类实现过,如果是,则需要针对每份实现分别进行下列步骤 声明一个新函数,名称与原函数相同,只是加上新添加的参数,将就函数的代码复制到新函数中 修改就函数,令它调用新函数 删除旧函数,如果旧函数是该类public接口的一部分,你可能无法安全的删除它,这种情况下,将它保留在原地,并将它标示为deprecated(建议不适用) 2 Change Bidirectional Asociation to Unidirectional(将双向关联改为单向关联) 使用取值函数,不ton过指针取得被引用对象,如果有可能,对取值函数使用substitute algorithm,从而让客户在没有指针的情况下也可以使用该取值函数 对于使用该字段的所有函数,考虑将引用对象作为参数传进去 如果硬没有任何函数使用待删除字段,移除所有对该字段的更新逻辑,然后移除该字段。 3 Change Unidirectional Association To Bidirectional(将单向关联改为双向关联) 两个类都需要使用对方的特性,但其间只有一条单向链接,添加一个反向指针,并使修改函数能够同时更新两条链接 在被引用类中增加一个字段,用以保存反向指针 决定由哪个类-引用端还是被引用端

flask @login_required重构

 ̄綄美尐妖づ 提交于 2019-12-02 15:08:53
flask 自带登录视图函数login_required,在前后端不分离情况下,我们可以直接调用官方的,但现在大部分项目都是前后端分离,以接口的形式出现,还有sign验证签名,下面是鄙人小改@login_required 实现登录视图验证和sign验证 源码: (代码不多,短小精悍,源码用到LoginManager模块这里不做详述) def login_required ( func ) : @wraps ( func ) def decorated_view ( * args , ** kwargs ) : if request . method in EXEMPT_METHODS : return func ( * args , ** kwargs ) elif current_app . login_manager . _login_disabled : return func ( * args , ** kwargs ) elif not current_user . is_authenticated : return current_app . login_manager . unauthorized ( ) return func ( * args , ** kwargs ) return decorated_view 在源码基础上进行修饰(其中make

为什么要持续重构

房东的猫 提交于 2019-12-02 14:44:38
为什么要持续重构 什么是重构? 重构是在不改变软件可观察行为的前提下改善其内部结构。---Martin Fowler 通俗说法:看起来没做啥调整,让系统继续更好的满足客户需求。同时,希望重构完成后,这个系统能够多蹦跶几年。    重构的分类: 代码重构   如果想了解代码方面的重构主要有哪些方法,可以参考《重构:改善既有代码的设计》、《重构与模式》。   之前我们在有次讨论的时候,一个童鞋说:“我们现在的程序设计都被框架封装了,设计模式基本是用不到的。”这个说法我不太同意。因为我们现在也在进行代码重构,抛去设计不谈,但从代码风格上,最令人吐槽的是里面充斥着大量的if和else。刚毕业的童鞋可以觉得很正常。但是稍有经验的人就知道这些逻辑计算应该用策略来代替。设计模式是从细节代码到设计架构处处充斥着的一门设计美学,任何工程师都需要掌握和学以致用。 架构重构   如果想了解架构方面的重构主要有哪些方法,可以参考《软件设计重构》。下面列了一些架构重构方面的主要考虑点,并对其中一点做了说明。   1>可扩展和负载均衡策略   2>数据库的读写分离和主从切换   3>按需扩容   4>两地三中心,机房故障也能稳定的提供服务   5>持续的容量规划   每个阶段都有自己的业务目标。订单量会对系统容量有新的要求。针对业务目标做评估,对组件做评估,看当前支撑的量是多少,找到其中的瓶颈点做架构升级

csharp进阶练习题:重构出一个switch语句的解释【难度:2级】--景越C#经典编程题库,不同难度C#练习题,适合自学C#的新手进阶训练

假如想象 提交于 2019-12-02 10:33:22
csharp进阶练习题:重构出一个switch语句的解释【难度:2级】: 团 这个习题的目的是重构了switch语句,并用字典"跳转表"代替 问题 尽管switch语句可以快速执行,是一个简单的结构,以掌握他们可以成为笨拙因为他们要增加维护的噩梦. 此外,他们不会轻易鼓励"打开关闭"的原则.考虑到这一点,我们会从代码中删除switch叙述,用它可以像一个"跳转表"中使用的辞典更换. 解决方案 您的解决方案将与到字典的呼叫替换 GetStatusDescription() 方法的 开关case statment.该词典将被宣布为beloww: 私人只读字典<状态,串> _statusDescriptions; 其中 Status 如下列举: 公共枚举状态 { 默认值= 0, 新= 1, 活动= 2, 停用= 3 } 注意: 是的测试将通过无为和离开 开关... case 构造存在,但这种习题的想法是给你的洞察你的代码删除`之开关语句和寻找替代构造,在此情况下,一本字典. 请享用. 附:如果你喜欢这个习题然后选择"使用多态重构出一个switch语句"是一个类似的静脉. 编程目标: using System ; public class Kata { private readonly Status _status ; public Kata ( ) { } public Kata (

重构ECShop中的Javascript(一)

戏子无情 提交于 2019-12-01 18:32:12
ECShop一直有一个很大的问题,就是其自带的JS脚本和jQuery为主的不少使用非常多的JS框架冲突,这个冲突导致了我们在制作ECShop模板的时候,很多优秀的界面效果无法实现。可以说是ECShop最让人诟病的地方。 在网上搜索了几天后,尝试了网上各种不同的解决方案后,发现部分解决方案只是针对某一部分ECShop的版本有效,而在新版中原本有效的解决方案再次失效,或者是只能解决部分jQuery使用的问题,但比较复杂的功能还是会冲突。最后一怒之下,决定一劳永逸地解决这个该死的冲突问题。 我的主要思路是,其实ECShop这些JS的主要功能中,基本上都可以被jQuery的功能替代,或者重写,也正是因为相同功能的不同实现在两部分中同时存在,才引发了这么多冲突。所以,只要把我需要的JS功能用jQuery重写,这个问题也就不存在了。 首先,我们需要先确定到底是哪些功能引起了冲突,这里我不能,也没有时间解决全部问题,因此,提出的仅仅是一个思路,和解决我所遇到的那一部分问题。如果在其他地方冲突,大家可以根据情况自行修改。 在制作模板的时候,我遇到的最大的问题就是在商品列表页和商品显示两个页面的模板中的添加购物车功能的Javascript与jQuery冲突。所以,我们先看看这个添加购物车的功能,究竟干了什么。在firebug中追踪添加购物车后的通讯,结果如下: 服务器端的回复如下: 随后

Kruskal重构树学习笔记

。_饼干妹妹 提交于 2019-12-01 17:23:39
Kruskal重构树学习笔记 为做这道题,特意去学了一波Kruskal重构树。 以下写写学习心得: 首先像Kruskal一样按权值排序, 不过将Kruskal生成树的并查集合并操作改为了 新建点,为合并的两点的父亲,点权为加入的边的权值的操作 作者不要脸地剽图了 变为: 有一些性质: 1.二叉树。 2.点权大根堆(Kruskal从小到大的排序,从小到大则反之) 3.两点间的最大距离为LCA的权值--->两点能否通过边权<=k的边互达:倍增跳到LCA是否小于等于k 例题1: 路径权值 Description   给定一个带权树,树上任意两点间的路径权值d(x,y)定义为x,y这两个点之间路径上的最小值,树上任意一点x的权值定义为这个点到树上其他所有点的路径权值和,即 \(\sum_{i=1}^{n} d(x,i)\) ,现求树上一点,使得这个点的权值最大,输出这个值。 Input   首先输入一个整数Q,接着每组数据首先输入一个整数 n(1≤n≤100000),表示该组数1据中树的点的个数。   接下来n−1行,每行三个整数 x,y,s(1≤x,y≤n,1≤s≤1000),表示编号为x的节点和编号为y的节点之间存在一条权值为s的边,树上每个点的编号为1~n Output   对于每组数据,首先输出数据编号,然后输出树上的点的最大权值,具体格式见输出样例。 Sample Input 2

IntelliJ IDEA 复杂的重构技巧

只愿长相守 提交于 2019-12-01 10:06:21
IntelliJ IDEA 复杂的重构技巧(二) 转载 上次我说了一些 “ 复杂的重构技巧 ” ,讲的是一些使用 IntelliJ 的简单功能实现复杂的重构需求的技巧。 看到大家的反响之后我就感觉那个可能不大亲民,因为很多人连 inline 这功能都不知道(那岂不是把 IntelliJ 用成了记事本), 于是我决定再写一篇讲讲 IntelliJ 已经提供好了的一些复杂的重构功能。 这就不再是需要自己进行奇奇怪怪的操作的教程了,就会亲民得多。 从方法中提取方法 这是用来快速复用一段代码的功能,名叫 “Extract Method” 。 比如,我现在有这么一段业务代码(顺带一提,这是在 Java 调用动态语言 API 时能使用的最健壮的处理数值类型的方法): liceEnv.defineFunction("run-later", ((metaData, nodes) -> { Number time = (Number) nodes.get(0).eval(); Consumer<Node> nodeConsumer = Node::eval; if (time != null) runLater(time.longValue(), () -> { for (int i = 1; i < nodes.size(); i++) { // 截图之前写的时候脑抽了,这个是后来改的