重构的理由

1.代码重复

2.子程序太长

3.循环太长或者嵌套太深

4.类的内聚性太差

5.类的接口的抽象层次不一致

6.参数表中参数太多

7.类的内部修改往往局限于某个部分

8.需要对多个类进行并行测试

9.对继承体系的并行修改

10.需要对多个case语句进行并行修改

11.相关的数据项只是被放在一起,没有组织到类中

12.成员函数更多地使用了其它类的功能,而非自身类的

13.过于依赖基本数据类型

14.一个类不做什么事

15.一连串传递流浪数据的子程序

16.中间人对象什么也不干

17.某个类同其他类关系过于密切

18.子程序的命名太差

19.数据成员被设置为公用

20.派生类紧使用了基类的一小部分代码成员函数

21用注释来掩盖拙劣的代码

22.使用了全局变量

23.在子程序调用前使用设置代码,调用后使用了收尾代码

24.程序包含的某些代码似乎在将来某个时候才会被用到

时间: 2024-08-06 03:41:55

重构的理由的相关文章

编程的97件事——6、在重构之前

在重构之前 每个程序员都会在某些时候需要重构已存在的代码.但在这样做之前请想想下面的问题,这会省去你和其他人很多时间(和痛苦): 开始重构的最佳时机是审查代码库和代码库的测试代码的时候.这时你明白当前代码的优点和不足,这可以确保你重构时保持代码的优秀特性并避免上个版本犯下的错误.我们都以为自己会比现存系统做得更好,结果并没有更好,还可能更糟-这是因为我们没有从前人的错误中吸取教训. 避开推到重来的诱惑.复用的代码越多越好.无论这些代码多么丑陋,这些代码毕竟是被测试和复查过的.丢弃旧代码,尤其是产

架构之重构的12条军规

原文地址:http://m.yuedu.163.com/reader/news/content.do?source_uuid=6a06e2c0-5865-4658-b609-c92ed95fadbd_1&content_uuid=4a0b1390a22e439ab8c28d5ddff14a87_1&isappinstalled=1&from=timeline 5月11日 00:00    来源:InfoQ中文站 [注]架构之重构的12条军规(上)发布以后,一些读者着急要下篇,所以在

架构的坑系列:重构过程中的过度设计

架构的坑系列:重构过程中的过度设计 软件架构   2016-06-03 08:47:02 发布 您的评价:       5.0   收藏     2收藏 这个系列是 坑 系列,会说一些在系统设计,系统架构上的 坑 ,这些都是我想到哪说到哪,有像这篇一样比较宏观的 坑 ,后面的文章也会有到具体技术细节的(比如某个函数,某个系统调用) 坑 ,总之,到处都是坑,这些坑有些是我经历过的,有些是听说的,你也可以留言说说你遇到的 坑 . 这一篇,我们从 重构 这个场景来看看系统架构的设计中 过度设计 这个坑

坑系列 --- 重构过程中的过度设计

这个系列是坑系列,会说一些在系统设计,系统架构上的坑,这些都是我想到哪说到哪,有像这篇一样比较宏观的坑,后面的文章也会有到具体技术细节的(比如某个函数,某个系统调用)坑,总之,到处都是坑,这些坑有些是我经历过的,有些是听说的,你也可以留言说说你遇到的坑. 这一篇,我们从重构这个场景来看看系统架构的设计中过度设计这个坑. 首先,我们这里说的重构,和<重构:改善既有代码的设计>这本书中的重构不太一样,这是本好书,他主要说的是代码级别的重构,这种重构是需要在编码的时候时时刻刻进行的,更多的是一种编程

《Code Complete》ch.24 重构

WHAT? 重构(refactoring),Martin Fowler将其定义为“在不改变软件外部行为的前提下,对其内部结构进行改变,使之更容易理解并便于修改”. WHY? 神话:一个管理很完善的软件项目,应该首先以系统化的方法进行需求开发,定义一份严谨的列表来描述程序的功能.设计完全遵循需求,并且完成的相当仔细,这样就让程序员的代码编写工作从头到尾直线型地工作.表明绝大多数代码首次编写后就已完美,测试通过即可被抛诸脑后.代码被修改的惟一时机发生在交付使用后在新版本进行功能的添加 现实:在初始开

软件架构————重构

软件演化的类型 软件演化就像生物进化一样,有些突变对物种是有益的,而有些是有害的. 区分软件演化类型的关键,就是程序质量在这一过程中时提高了还是降低了.其二,就是这样的演化是源于程序构建过程中的秀海,还是维护过程中的修改. 重构简介 要实现软件演化基本准则,最关键的策略就是重构. 重构的理由 1.代码重复,重复的代码几乎是代表着最初设计里彻底分解方面的一个事物.无论何时,如果需要对某个地方进行修改,你都不得不在另一个地方完成这样的修改--重复代码总会将你置于一种两线作战的尴尬境地. 2.冗长的子

第二十四章 重构

重构简介 重构定义: 在不改变软件外部行为的前提下,对其内部结构进行改变,使之更容易理解以便于修改: 尽可能地将一个程序分解为多个组成部分. 重构的理由 代码重复: 冗长的子程序: 循环过长或嵌套过深: 类的接口未能提供层次一致的抽象: 拥有太多参数的参数列表: 类的内部修改往往被局限于某个部分: 变化导致对多个类的相同修改: 对继承体系的同样修改: case语句需要做相同的修改: 同时使用的相关数据并未以类的方式进行组织: 成员函数使用其他类的特征比使用自身类的特征还要多: 过多使用基本数据类

《软件构架实践》阅读笔记05

软件构架是控制软件复杂性.提高软件系统质量的重要手段,然而在现实当中,当我们写一个程序或做一个系统时,并不是一步完成的,可能需要及时更新不同的版本.同样,构架重构也是十分必要的,它是一种解释.交互和迭代的过程,涉及很多活动.软件构架重构由信息提取.数据库构造.视图融合.重构这些活动组成,它们以迭代的方式进行. 顾名思义,信息提取就是从各种源提取信息,信息提取设计分析系统现有的设计和实现制品,以构造系统的模型,所得到的结果就是放在数据库中的信息结合.提取信息使用的各种工具,如解析器.抽象语法树分析

《代码大全2》学习笔记3

第三.四部分--变量.语句 "在声明变量时初始化"--减少未赋值的风险. "尽可能减少变量的存活时间"--感觉如果按照推荐,一般子程序都写的很短,那么这个也就不重要了吧. "一个好记的名字反应的通常是问题,而不是解决方案,是what而不是how" "避免使用相似含义的名字,如果你能让2个变量交换名字还不妨碍理解的话,就说明都要重新改名了."--越功能简单越名字容易相似,哪那么好改啊. "避免使用数字,什么file1,