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

重构,改善既有代码的设计--第一章感悟

一、书中经典句子


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.修补错误时候重构:在重构中来找出系统的bug

3.复审代码时候重构

4.个人觉得在功能完成之后顺便重构会更好,因为在那个时候对代码还是很熟悉,还有可以在重构的时候去发现开发过程中遗留下来的bug

重构,改善既有代码的设计--第四章感悟

1.类应该包含它们的测试代码。每个类都应该有一个测试函数

重构,改善既有代码的设计--第六章感悟

以下摘自书中内容:


一.对付过长函数的方法


1.Extra
Mehtod:就是把一段代码才从原先函数中提取出来,放入一个单独函数中。最大困难就是处理局部变量。(创造新函数要根据这个函数的意图来对它命名,以它“做什么”来命名,而不是以它“怎么做”命名。)

二、内联函数


当函数本体和名称同样清晰易懂需要合并两个函数:如:


    int _moreThaFiveLateDeliveriens=0;
public int getRating() {
return (moreThaFiveLateDeliveriens())?2:1;
}

boolean moreThaFiveLateDeliveriens()
{
return _moreThaFiveLateDeliveriens>5;
}

变成


    int _moreThaFiveLateDeliveriens=0;
public int getRating() {
return (_moreThaFiveLateDeliveriens>5)?2:1;
}

三、内联临时变量


double basePrice=anOrder.basePrice();
return (basePrice>1000);
改为

return (anOrder.basePrice()>1000);

四、找变量做法


1.找出只被赋值一次的临时变量;如果某个变量被赋值超过一次,考虑将它分割为多个变量,

将该变量声明为final。

2.将复杂表达式的结果放在一个临时变量,以此变量的名称来解释表达式用途。

3.对那些被赋值不止一次的临时变量,需要针对每次赋值,创造一个独立、对应的临时变量。将新的临时变量定义为final类型。

比如:int a=2*3(10+11);

     a=1*121*1111;

换成:int a=2*3(10+11);

     int b=1*121*1111;

重构,改善既有代码的设计--第七章感悟

1.提炼类


某个类做了应该由两个类做的事,需要建立一个新的类,将相关的字段和函数从旧类搬到新类。

先搬较底层函数(就是给别人调用多过于调用别人的),再搬高层函数。

重构,改善既有代码的设计--第八章感悟

1.如果你看到一个数组的行为方式很像一个数据结构,就可以把数组变成对象

private int aa,变成:  int aa;

public int GetAA()
{return aa;}//好处:使得获取的数据更加有效

时间: 2024-11-06 01:30:28

重构,改善既有代码的设计--总结篇的相关文章

《重构--改善既有代码的设计》总结or读后感:重构是程序员的本能

此文写得有点晚,记得去年7月读完的这本书,只是那时没有写文章的意识,也无所谓总结了,现在稍微聊一下吧. 想起写这篇感想,还是前几天看了这么一篇文章 研究发现重构软件并不会改善代码质量 先从一个大家都有的经历说起吧. 刚开始学编程时,比如,要统计数字出现的次数,我们会这么定义变量 int i=0;//统计次数 老师看了说,代码要有可读性,见名知意; 于是,我们把它改成 int count=0; 后来才知道,原来这么一手这就是重构的第一式,重命名 (eclipse快捷键 alt+shift+R,最近

《重构——改善既有代码的设计》读书笔记

重构--改善既有代码的设计 1 重构概述 1.1 重构的概念(What) Refactoring 名词:对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低修改成本. 动词:使用一系列重构方法,在不改变软件可观察行为的前提下,调整其结构. 1.2 为什么要重构(Why) 改进软件设计 提高代码质量和可读性,使软件系统更易理解和维护 帮助尽早的发现缺陷 提高编程速度 1.3 何时重构(When) 何时重构: 1)随时随地进行. 2)三次法则:第一次做某件事只管去做:

【转】PHP 杂谈《重构-改善既有代码的设计》之一 重新组织你的函数

原文地址: PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数 思维导图 点击下图,可以看大图. 介绍 我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙. 如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了. 代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服. 专业术语 我们毕竟是用英文

重构改善既有代码的设计思维导图

最近闲来无事就把之前看的书,做了一张张的思维导图,来分享给大家 重构改善既有代码的设计思维导图: --------------- 不知道是博客园的问题,还是我的浏览器的问题,图片没法上传,如有人想要想看 可以给我发邮件: [email protected]  只为共同学习.也可以留言!!!

好书推荐之:重构-改善既有代码的设计

下载地址 高清 1.3M 重构-改善既有代码的设计 版权声明:本文为博主原创文章,未经博主允许不得转载.

《重构&mdash;&mdash;改善既有代码的设计》【PDF】下载

<重构--改善既有代码的设计>[PDF]下载链接: https://u253469.ctfile.com/fs/253469-231196358 编辑推荐 重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码.多年前,正是<重构:改善既有代码的设计>原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分.<重构:改善既有代码的设计>也因此成为与<设计模式>齐名的经典著作,被译为中.德.俄.日等众多语言,

实践提高《重构改善既有代码的设计第2版》PDF中文+PDF英文+对比分析

重构是编程的基础,是在不改变外部行为的前提下,有条不紊地改善代码.编程爱好者都知道,Martin Fowler 的<重构:改善既有代码的设计>已经成为全球有经验的程序员手中的利器,既可用来改善既有代码的设计.提升软件的可维护性,又可用于使既有代码更易理解.焕发出新的活力. <重构改善既有代码的设计(第2版)>在第1 版的基础上做了全面修订,反映了编程领域业已发生的许多变化.第2 版中介绍的重构列表更加内聚,并用JavaScript 语言重写了代码范例.此外,第2 版中还新增了与函数

【重构.改善既有代码的设计】14、总结&amp;读后感

14.总结 首先,这是一本太老的书,很多观点已经被固化或者过时了.但核心观点没有问题,虽然大多数观点已经被认为是理所当然的事情了. 重构的定义 重构分几种: 1.狭义的代码重构   就是本书讲的,在不改变软件可观察行为的前提下,改变其内部结构.这就是完全不改变程序的功能,只是改变代码的组织方式,也就是只是整理代码而已,目的是优化代码架构,而不是优化行为.算法.逻辑或流程. 2.普通意义的重构 事实上,我们一般很少会去做纯粹的重构,所以,了解了软件行为,从行为.算法.逻辑或流程上进行优化,,往往会

《重构-改善既有代码的设计》读书笔记

重构,第一个案例 1.1 起点 如果发现现有的代码结构使你无法很方便地添加新特性,那就先重构,使特性的添加比较容易进行后,再添加特性; 1.2 重构的第一步 为即将修改的代码建立可靠的测试环境 – 是人就会犯错,所以需要可靠的测试; 测试结果能够自我检验 – 成功"OK",失败列出失败清单并打印行号 (自动化对比测试结果是提高效率的前提); 1.3 分解并重组"巨型"函数 切分提炼长函数(Extract Method),并移至更合适的类(Move Method) –