代码坏味道特征重复的代码

重复的代码开发,在作为初级的程序员是经常遇见的,因为被要求做一些很固定且比较简单通用的模块,所以很容易就遇上功能相同的代码进行重复的开发了。

1.为什么会有重复的代码

重复的代码可能会出现编写人员抽象公有模块抽象公有功能的能力,可能来自我们开发方式过于老化固定了类之间的相互应用所以导致编写的某一个功能只适用一个特定的系统使用,可能来自我们的设计人员对项目框架设计考虑不够仔细,没有重用性的设计过程。

2.怎样避免出现重复的代码

使用完善的SOA框架,我认为至少在我们内网程序开发中可以节约一大部分的工作,比如在一个大的公司里面一个文件同时会涉及到被多个领导经过多级审阅才能最终完成,所以我认为可以吧这样审阅的功能做成可以配置的服务发布在内网系统之中,只要有这样的一种思想经过长期的积累与改进,一两年之后再某一个领域的相应的服务或中间件几乎覆盖了主要的业务流程,开发人员可以像搭建积木一样的快速搭建出功能模块,开发人员的主要工作就是把页面做的更加的美观,更加的实用方便。

第二种方法就是建立主键库,把我们编码中出现的公用功能进行不断的收集封装成为dll文件每当下一个项目需要的时候可以直接进行引用该封装的中间件。

第三种方法就是在具体开发过程中无论你是实用java或C#这些语言都是支持泛型和反射的能够熟悉的使用这种编程方法可以极大的减低代码的耦合性提高代码的重用性。

以上就是从三个方面架构设计,主键库和具体编码方法中总结了避免重复代码的方法,以后再项目建设中不断优化不断完善。

3.遇到重复的代码该怎么办

但是在编程中遇到重复的代码功能不可避免的,做项目的程序员和做产品的程序员两个的理解各不一样,做项目的程序员重点不会是重构抽象让代码做的足够的精细,为什么呢?因为做项目之后再程序员主要看进度,程序员没日没夜的推进着项目功能的不断建设,他们只希望项目能够快速做完快速得到验收然后拿钱......因为他们做完一个项目就会转向做另外的项目,不断做项目他们才能有不断的收获。但是做产品的兄弟可能一辈子就投入到一两个产品之中他们的一身就是为了把一个产品做的足够的完美,所以在代码层面上要做的足够的完美,如果代码做的不仔细那没后面的维护代价都得自己来抗,有一点得不偿失,所以他宁愿功能开发推迟两周出来也要保证退出来的产品能够做到足够的稳健漂亮且令人赏心悦目。

所以在遇到重复的代码的时候应该衡量自己所处的位置评价去抽象达到代码公用的代价,找到一个衡量点然后再采取行动——消不消灭这样的重复的代码。

代码坏味道特征重复的代码,布布扣,bubuko.com

时间: 2024-12-27 11:21:33

代码坏味道特征重复的代码的相关文章

吐槽一下项目中的代码坏味道:滥用java常量

我们的项目中是否充斥着类似下面的代码呢?定义一个专门存放常量的java类(接口),很多其他类依赖该常量类. public interface IConstant { int ZERO = 0; String EMPTY_STRING = ""; } 使用该常量的代码,大致具有如下形式: List<String> list = new ArrayList<String>(IConstant.ZERO); if(IConstant.ZERO == list.size

代码坏味道之令人迷惑的暂时字段

为什么我们随意命名变量会是灾难性的决定? 随意命名变量是编写代码的灾难性决定,我这里说的比较严重,但是为了强调编程过程中不要随意命名我们的变量.因为从以下三方面的理由是不允许我们在程序中随意命名变量的.首先在编程过程中,随意命名的变量会导致我们编写代码中弄乱数据传输的关系,因为人们通过混乱的字段会把字段的本意理解错误的,理解错误字段的意思就会把该字段用在本不该她使用的地方.其次,当你费尽千辛万苦程序终于能够运行了,但是面对需求变更或代码给其他人阅读的时候,会给阅读人带来很大的难度,因为当别人来阅

代码坏味道之过大的类

1.为什么会出现过大的类 我们的编码过程中,不知不觉的就把一个类编写的非常的庞大.为什么会这样子呢?我想无非由两个理由,首先是编码过程中为了贪图一时的方面不想动手去添加一个类用来管理不属于原先这个类的职责.其次整个系统使用了太多的继承关系,无形中就会造成子类变得异常庞大.总之,如果想利用一个类做太多的事情,往往就会造成这个类变得异常庞大.8 2.过大的类会照成什么严重后果 既然出现了过大的类,那么他到底会造成什么严重的后果呢?首先很明显一点过大的类在开发中难以调试并且在后期维护中可能因为功能的变

代码坏味道之过长的参数列

1.为什么会出现过长的参数的函数呢? 出现过长的参数列,我们在编写程序的时候职责划分不清晰,一个函数做了太多的事情,可能会让调用者传入更多的参数进行功能的实现.第二函数封装不合理,导致调用函数的内部变量成为封装函数的参数. 2.当我们遇上了过长的参数函数怎么办? 当我们遇上了过长的参数列的函数有两种方法来解决,第一,通过重载参数把程序中暂时不需要的函数的参数进行封装,减少过长的参数列.第二,通过封装参数列对象,在封装的时候尽量将职责相近的参数放在一起,这样做提高了封装对象的内聚性. 3.怎样避免

代码坏味道之夸夸其谈的未来性

1.为什么会有夸夸奇谈的未来性呢? 当我们谈到这个问题的时候,我们就要反思在需求理解和设计的时候对程序变动性的理解出现了偏差."哦,我想我们总有一天炫耀做这事儿的"常常是一念之差导致的代码坏味道.总结有以下四点原因是经常导致出现夸夸奇谈未来性的原因.第一.经常在理解需求的时候主观的认为需求变动非常大,那么在设计过程中就会出现过度的设计.第二.追求设计模式的使用,经常对程序的不必要的地方进行设计模式的使用,导致代码不易理解.第三.程序的设计过程中封装变化混乱,没有将封装变化进行到底.最后

『重构--改善既有代码的设计』读书笔记----代码坏味道【3】

星期六了,适当出去放松了下,回来继续我们重构的话题.今天是坏味道[3]了,很多朋友跟我私信,叫我把坏味道出完,再出手法.其实这是有道理的,很多时候,"发现"远比"怎么做"重要的多.就拿设计模式来讲,GoF里面的设计模式相信有很多人都了解过.具体的设计模式应该怎么实现啊相信有很多人都背的滚瓜烂熟,但问题的难点往往在于你应该什么时候用这个设计模式.重构也一样,手法步骤都是死的,关键在于应该发现什么时候应该重构.所以,我还是决定继续出坏味道,把坏味道全部出完我们再去学手法

代码坏味道 - 耦合

耦合 Feature Envy 症状: 方法访问其他类的对象的属性,而不是自己的. 成因: 最常见的问题就是由数据类引起的. 治疗: 多数时候,同时需要做出改变的code 应该在一起. 收益: 不合适的亲密 症状: 一个类有大量的访问另一个类的属性和方法,类之间的联系千丝万缕. 成因: 治疗: 变双向依赖为单向 单点接触 收益: 消息链 症状: a.b().c().d() 有什么不好吗? 客户对这关系知道的太多了,修改关系就意味着修改所有客户. 成因: 治疗: 隐藏委托,变单点接触.a 通过b

javascript编程中一种常见的代码坏味道:Pyramid of doom(金字塔厄运)

Pyramid of doom说的是代码嵌套层次太深,太多的代码缩进,导致代码横向增长大于纵向增长.非常影响代码的可读性,因为我们看不清嵌套关系,很容易弄错变量的作用域,大括号多了或者少了等问题. 代码1:if层次过深 bool conditionA = executeStepA(); if (conditionA){ bool conditionB = executeStepB(); if (conditionB){ bool conditionC = executeStepC(); if (

代码坏味道

肿胀 代码,方法或类膨胀到难以维护,一般是长期积累形成,从未人尝试瘦身. 这包括: 长方法,大类,长的参数列表,偏爱使用原始类型,数据块 对 OO 的滥用 对面向对象原则的不正确或一知半解. switch 语句, 临时字段, 拒绝继承,Alternative classes with different interfaces 阻碍改变 修改一处,要同时修改很多处.程序开发变得越来越复杂和麻烦. Divergent Change , Shortgun Surgery, Parallel Inher