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

1.为什么会有夸夸奇谈的未来性呢?

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

2.为什么夸夸其谈的未来性不好呢?

过度的设计导致代码不易理解和错误不易定位,也许还会降低代码执行的效率。当程序中过量的使用设计模式,导致在代码的阅读过程中很难找到主要的逻辑走向。放置过量的钩子或特殊情况来处理一些非必要的事情,可能在代码的编写调试过程中加深跟踪Bug的难度。

3.面对夸夸奇谈的未来性的最佳实践

那么我们怎么处理呢?面对一个需求点的时候尽量使用最小的改动最少的变化满足需求的功能点,那么我们的程序要怎样面对变化呢?首先要明确一点这个变不变,不单单是来自设计师的合理思考设计最主要还是来自用户的业务需求。如果面对一个业务需求的变化,在进行了需求访谈之后用户明确这一部分需求变化很大而且明确的变化点,那么再重构程序使用设计模式、放置钩子或特殊处理装置来应对他的未来性。一定要注意不要使用过量的人力物力过量的钩子或特殊装置来处理那些自己认为的变化点。变不变化主要还是要看用户的业务需要的。

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

时间: 2024-11-09 19:30:04

代码坏味道之夸夸其谈的未来性的相关文章

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

重复的代码开发,在作为初级的程序员是经常遇见的,因为被要求做一些很固定且比较简单通用的模块,所以很容易就遇上功能相同的代码进行重复的开发了. 1.为什么会有重复的代码 重复的代码可能会出现编写人员抽象公有模块抽象公有功能的能力,可能来自我们开发方式过于老化固定了类之间的相互应用所以导致编写的某一个功能只适用一个特定的系统使用,可能来自我们的设计人员对项目框架设计考虑不够仔细,没有重用性的设计过程. 2.怎样避免出现重复的代码 使用完善的SOA框架,我认为至少在我们内网程序开发中可以节约一大部分的

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

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

吐槽一下项目中的代码坏味道:滥用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.过大的类会照成什么严重后果 既然出现了过大的类,那么他到底会造成什么严重的后果呢?首先很明显一点过大的类在开发中难以调试并且在后期维护中可能因为功能的变

代码坏味道 - 耦合

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

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

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

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

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

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

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