重构学习-重构原则

什么是重构:



视上下文重构有两个不同的定义,第一个定义是名词形式

对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本

重构的另一人用法是动词形式

使用一系列的重构手法,在不改变软件可观察行为的前提下调整其结构。

有人说重构就是整理代码 ,从某种角度上来说,是,但是重构不止于此,因为它提供了一种更为高效且受控的代码整理

技术,运用代码重构技术后你会发现对代码的整理会比以前更加高效。

重构的目的是使软件更容易被理解和侯。你可以在软件的内部做很多修改,但必须对软件可观察的外部行为只造成很小

的变化,甚至不造成变化。与之形成对比的是性能优化。和重构一样,性能优化通常也不会改变组件的行为,只改变执行

速度,只修改内部结构。两者的出发点不同,性能优化可能会使代码较难理解。

强调一下,重构不会改变软件的可观察行为,也就是说重构之后功能和原来一样。

为什么要重构:



重构改进软件设计,如果没有重构,程序的设计会逐渐腐败变质。好多时候我们为了马上解决问题,就直接修改程序,程序

逐渐失去了自己的结构,这样下去程序会越来越难理解。重构就是整理代码让代码回到应处的位置上。

完成同样一伯事情,设计不良的程序会往往需要更多代码,这常常是因为代码在不同的地方使用完全相同的语句做同样的事。

改进设计的一个重要原因就是消除重复代码。代码的减少不会使系统运行的更快,因为这对程序的运行没有任何明显影响。然而

代码的减少将使未来可能的程序修改动作更容易。代码越多修改起来就越麻烦,因为有更多的代码需要阅读和理解。如果消除

重复代码,你就可以确定所有事物和行为在代码中只表述一次,这正是优秀设计的根本。

重构可以让我们的代码更容易理解和阅读,也可以帮助我们找到bug

什么时候进行重构:



事不过三,过三就重构这个原则要记住,第一次去做某件事时只管去做,第二次再去做类似的事就会不爽,但无论如何还是可以

去做,但第三次再去做类似的事件,你就应该重构。

重构的直接原因往往是帮助我理解需要修改的代码,这些代码可能是别人写的,也可能是我自己写的。无论何时只要我想理解代

码所做的事,就会问,是否能对这些代码进行重构,使我能快速理解这它,那我就会对它进行重构。

重构的原动力是:代码设计无法帮助我轻松的添加我所需要的功能,如果用某种设计方式,添加功能会简单的多,这种情况可以用

重构来弥补。重构是一个快速流畅的过程,一旦完成重构,新特性的添加会更快速,更流畅。

如果在修改bug和审查代码时发现不合理的地方也要进行重构,这样是为了更好的阅读和理解代码

何时不重构:



如果发现代码太混乱,重构它不如重写来的简单这种情况下建议重写,不用进行重构。

如果项目已经进入了最后期限,那也应该避免重构,这时已经有些晚了。最后你没有时间进行重构表明你其实早就该进行重构了

重构与性能:



有时为了让代码更容易理解,会做出一些使程序运行变慢的修改,这是个重要的问题。这个的解决方案是先写出可高试的软件,然后

调整它以求获得足够的速度。

重构学习-重构原则,码迷,mamicode.com

时间: 2024-08-08 09:41:34

重构学习-重构原则的相关文章

【重构学习】序

话说写代码的时候越来越认识到了重构的重要性. 作为一个有良知的程序员,我觉得我们确实有必要写出让人明白的代码,而不是仅仅让计算机明白. 更加重要的是我意识到重构能让我在六点钟直接下班走人,而不是持续在Dirty Code里挣扎. 所以我决定去学习重构来提升我的技能. 然而意识到我并不是一个有毅力的人,所以我决定开博客,每天强制写东西来推动学习.

【重构学习笔记】

重构的定义:重构是对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本 从定义里我们可以看出,重构是对代码和架构的一种修改,旨在提高代码的效率和可读性,来达到降低修改成本的目的.而重构对于用户体验来说,就像定义中说到的,只能对可观察行为作出很小的变化,甚至不造成变化. 关于同事些代码经常会把DAO注入到表现层Controller里面使用,我一直很反感这样的做法,奈何找不出可以反驳这些老员工的理由,确实才疏学浅了. 认真想想 例如,一般情况,我们会在Ser

C#重构学习2

转帖重构学习 重构?代码坏味道?看到这两个疑问,也许就知道本期的话题是关于“重构”的,重构无处不在,重构可大可小,重构随时随地.让重构时刻记在脑海,使自己的代码变的优美.就让这本“重构艺术”手册带你走进重构的世界,亲密接触重构,如欣赏艺术般,体会重构的魅力. 文章下载地址:http://files.cnblogs.com/xia520pi/C_Sharp_Refactoring.rar 文章的目录: 1.代码重构 1.1.版权声明 1.2.内容详情 2.项目重构方案设计 2.1.版权声明 2.2

学习重构(1)-代码的坏味道

前言:最近做一个特性,参照原有逻辑增加某个功能,老代码本身存在两套相似的流程,再添加上一套流程后,发现代码的重复度及其的高,基本可以理解为一套框架流程复制出来3个类,给3个功能使用.我对比了每个类的代码后,发现代码重复度基本在50%以上,这种代码真是越写越烂的感觉.于是费力的做了一下重构,搞了个父类出来,抽取了大部分公共函数,整体代码看着就舒服多了.草草做了下重构后,突然觉得自己并不系统的知道要如何重构,只是知道些皮毛,又自我感觉良好的样子.翻出很久都没电的kindle,本想买本重构的书看,突然

学习重构(0)-目录

何时重构 如何重构 代码坏味道 Duplicated Code(重复代码) 重新组织函数 Extract Method(提炼函数) Long Method(过长函数) Inline Method(内联函数) Large Class(过大的类) Inline Temp(内联临时变量) Long Parameter List(过长参数列) Replace Temp with Query(以查询取代临时变量) Divergent Change(发散式变化) Introduce Explaining V

设计模式之美学习-重构

为什么要重构 重构是时刻保证代码质量的一种手段,避免代码腐化到不可维护的地步,同时也是避免前期过度设计.优秀的产品都是迭代出来的,我们不可能提前预知未来需求,所以重构也是无法避免的. 重构的二种方式 大型重构 对 系统.模块.代码结构.类与类之间的关系等的重构,重构的手段有:分层.模块化.解耦.抽象可复用组件.此类重构会对代码的改动比较大,影响比较深. 比如我们的代码中有很多if else 判断 我们重构提取一个抽象 然后根据条件创建不同的处理类 小型重构 对类.函数.变量等代码级别的重构,比如

什么时候该重构--《重构》阅读笔记

当出现以下问题的时候,就要开始重构代码. 1)重复代码 重复代码在业务逻辑相同的地方,抽成方法.重复代码在业务逻辑不同的地方.抽成类. 2)long method 其实这个问题很多时候都碰到.我觉得原因主要还是两个.一个是修bug的时候,不敢改.因为这玩意,要改的话,压力还是很大的.还有一个写好之后,懒的改.这一种,特别实在这一次看书的过程中,觉得重构完全可以发生在刚写好代码的时候.因为我们写代码的时候,本能就是先实现功能.然后再考虑代码改如何组织. 3)large class 同上. 4)lo

【重构学习】 04 重构与设计模式

好吧,<重构>这本书的第五章,主要是对即将要写到的一些具体重构手法的写作结构的一种描述,并没有什么重要的东西. 仿佛是为了庆祝元旦的放假,特意给我准备的章节,为了让我完成今天的任务而特意水了一章. 好吧,还是有一句重要的话:设计模式为重构提供了目标,而重构是到达之路. 以下是我的废话,大神莫笑: 如果你不明白设计模式是什么?不要紧,就算你不明白也不要紧. 因为很多人学了设计模式都会忘掉,有的时候是因为他们不用,所以忘了.有的时候是因为用的多了,所以忘了. 如果是后者那就是无招胜有招的境界,如果

【重构学习】03 重构与测试

新的一年了,我却在这里写这个鬼 <重构>的这一章主要是讲java的一个测试框架,我直接就跳着看了 只是简单的看了一下它的思想 重构需要一个良好的测试体系,而我们需要为重构构建一个这样的体系,这是重构的前提 不需要期待完美测试,需要的是不完美的测试已经在实际执行了 测试的时候考虑可能出错的边界条件,并集中火力 不要因为测试无法捕捉所有BUG就不写测试,至少它可以捕捉大多数 花合理的时间抓出大多数BUG 写测试代码去让其执行自动化测试 好了这就是本章主要的内容 不太多,就来简单谈一下自己对测试的理