代码整洁之道读后理解

  1. 云栖社区>
  2. 博客>
  3. 正文

代码整洁之道读后理解

fewafd 2018-07-27 14:57:22 浏览1328
展开阅读全文

一,关于程序员的价值观

对于一个程序员来说,是应该有价值观的,然而最朴素的基本价值观,就是要写好的代码。然后,要做到这一点不容易,

对些,我针对这些价值观有自己的一些看法:
(当然,在网上有关于价值观的内容一大片,各有视角,这里仅仅说说我的看法)

1,good software != quality code

2,软件开本 = 开发成本 + 维护成本

注意,尤其是维护成本,被很多程序员所忽视,认为我只在几天开发完了这个代码,这个软件的成本就并不高,这个观念万万要不得。 久而久之,这个观点慢慢地被产品,项目经理所学习到,也自然而然的认为,只在几天内开发完的功能,所投入的成本并不高。然而残酷的事实是,投入维护它的成本数倍于甚至数十倍于开发成本,扔下的往往是一个烂摊子,后续接手的开发人员也会苦不堪言。

有时候,我们程序员总感觉自己被产品催着,有忙不完的事,而背后的原因往往是程序员自己本身,因为在与产品沟通过程,总是会释放出这个很容易,那个也很简单的信号,而给产品造成错觉。

3,代码就是债务

同样的功能,写的代码越多,相应的测试、维护、升级等等成本也越高。 尤其是过度设计的危害,太过于高瞻远瞩,而忽略现实情况,结果可能恰得其反。

还有一个是不得不说的:关于设计和代码。我们期望的是设计与代码无限接近,但是,现实中,设计与代码往往是脱离的,甚至有时候看到设计,对代码的理解反而是一种误导。不仅无助于还原软件的真实面目,反而让软件蒙上神秘的色彩。

程序员之间沟通,最佳的语言就是代码,代码说了什么,就是软件实际运行的真实表达。

有一个观点我需要表达的是:代码写出来,除了要运行之外,就是为了给别人看的。而后者,有很多程序员会忽视,甚至都没有意识。 如果有程序员认为,写出来的代码,只要能运行,有高效率,有什么可动态扩展等等就可以了,至于别人能不能看得懂,那可就不关我的事了。事实上,这个观点很有害。如果只是说代码能执行等等这些观点来看的话,那么,什么格式化,变量命名规范等等都可以不要了,甚至换行都不是必须的。

二,关于代码的坏味道

关于这一点,不得不承认,代码很难做到一点坏味道也没有。

但我想表达的时,我们需要培养这种嗅觉。 如同一个摄影师,要想出好的作品,首先需要培养审美能力,否则,再好的器材,也出不了好作品。

培养了对坏味道的灵敏嗅觉,一旦在自己的代码中闻出了不好的味道,就会有强迫症一样逼迫自己去消除之。 (我们假定一个合格的程序员,有那么一点点代码洁癖,看到不好的代码总会坐立不安,在不需要别人的催促下能自己消除坏味道。)

代码中有哪些常见的坏味道,在互联网上能搜索出一大堆,在此,我只列举一些,有空无空看一眼,以培养自己嗅觉。

  • 1,重复的代码
  • 2,过长的函数 (函数的代码过长)
  • 3,过大的类
  • 4,过长参数列表
  • 5,发散式变化
  • 6,霰弹式变化

第5点和第6点有时感觉很接近,发散式变化主要是指软件在某个细节点需要增加相同的功能,如原来支持mysql,现在要增加对postgre数据库的支持,则要修改若干个函数。而霰弹式更强调细节,如代码中要增加或变化某个变量的,若干个类也需要做许多细小的修改。 发散式一般指一个class受多个变化影响,而霰弹式则指一个变化引起多个class要做修改。 但我觉得刻意去记清这个差异没有必要。理解它的本质就行:一个地方微小的变化,总会引起若干地方有关联的变化,如果有这种情况,就要警觉是否有坏味道在产生了。

  • 7,依恋情结

函数对某个class的兴趣比自己的所在class兴趣还要高,这个比较难以理解,如,一个函数中,一大半的代码都在调用某一个类的方法,如取值等。

  • 8,数据泥团
  • 9,基本类型偏执
  • 10,switch statement

这个没啥好说的,面向对象最好少用switch , 尽量用多态,不过,也要分情况,不要杀鸡用牛刀了。

  • 11,平等继承体系

如: A extends SuperA , B extends SuperB , 如果有需要定义 AA extends SuperA时,总需要需要定义 BB extends SuperB 。 当然,这种也要会情况来对待,如果两边各代表一系列的继承关系,这个味道就不对了。

  • 12,冗赘类

定义一些无用的类,或者考虑的某种变化根本不可能存在,而代码中却有大量相关的类实现定义等。总之就是想得太多,但实际不会出现。

  • 13,夸夸其谈的未来性

在定义类时,总想着在未来的某一天会用到,而提链出一堆抽象类,接口等,而实际上,却无用处,甚至测单元测试也用不到。纯粹为了复杂而复杂。常见的情况就是,某些程序员总是无脑地定义抽象类,定义各种复杂的继承关系。

  • 14,Temporary Field

类中的一部分属性,只有在特定的方法才有作用,而这些属性,往往又不对外暴露。常见的是把某些方法的临时变量,作为类的属性。

  • 15,过度耦合的消息链

这个比较通俗的理解是: a调b,然后a调c, 然后又有b调c等等,可以改在 a调b, b调c。

  • 16,Middle Man (中间转手人)

委托(delegation)的过度使用,而且这个委托人不干实事。

  • 17,狎狔关系

两个class关系太过于亲密。这一点有点难以嗅到,不过,当发现用一个两个class类时,感觉用其中一个类时,又不得不花时间这个类的私有成员或者另外一个类的内容,两者很难分清它们之间的关系,往往会这种坏味道。这种情况下,相办法拆散它们,让他们关系明确一些。

  • 18,Alternative Class with Different Interface (异曲同工的类)

两个函数做着同一件事,却有着不同的签名,请按照用途重新命名或者其它方法消除这种表达不一致的情况。

  • 19,Incomplete Library Class (不完美的程序库类)

这一点我理解倒不像是一个坏味道,更新是在某些特殊场景下解决方法。
引入第三方的库不可能能满足所有需要,遇到这种情况,可以尝试引入外加函数或者引入本地扩展来解决这个问题。当然,这个是要分情况的,不能一概而论。

而如果要求第三方库完美,满足所有情况,这个就有点要求过度了。

  • 20,Data Class (幼稚的数据类)

常见一些看上去像bean的java对象,它的属性,除了有get/set方法外,我们还发现这些属性居然是public的,有的属性是容器等等,这样的代码看上去像是无脑的代码,哪些属性能够public,容器对象应不应该这样暴露出来,都没有思考,只是知道这样可以修改这些属性的值而已,至于这样写,会造成什么危害,对模型的数据和行为定义是否准确完成没有考虑过。

  • 21,Refused Bequest (被拒绝的遗赠)

这个坏味道有时并不那么强列,SubClass 继承了 SuperClass,但是又不支持SuperClass的接口,这个一般情况也就无所谓,当然,这么做有那么一点点别扭,但是,不要因此去随意改变模型间的继承关系,可以尝试用委托(Delegation)。

  • 22,过多的注释

这一个的正确理解是:一个本身很简单的功能,因为实现的代码过于糟糕,而造成注释不得不随之变长,而使得内容难以理解。 因此,不要一看到这一点就惊呼,不是提倡代码要写注释么,注释要详细么,怎么这又说是坏味道了,注意,不是这样子的,要正确理解。

总结:以上的坏味道,有些是可能存在争议或者只在某个场景中才算,所以,对于这些场景应理解其本质所要反映问题的本质,区别情况对待。但是,这不妨碍对于这些坏味道的识别,却培养一个码农应具备最基础的嗅觉能力。
另外,对于出现了坏味道的代码,也不太可能一味地追求去消除它,毕竟追求极致是要付出时间成本的,而且有些时间会出现首鼠两端的情况,一定要权衡利弊。

三,一些所要了解的基本常识

  • 1,圈复杂度
  • 2,创建子程序的理由:

    • 职责单一原则
    • 封装变化
    • 引入中间或者易懂的对象,使得代码更易懂
    • 避免重复代码
    • 简化复杂的布尔判断
    • 提高可移值性

      ....
      
  • 3,使用异常代替直接返回错误码

    • 可以使错误处理从主路径中分离出来,使主流程清淅易懂
    • 使用错误码返回易导致深层次嵌套
    • if条件判断中,鼓励使用指令函数去替代复杂的判断表达式

这一点,会有使用异常会影响性能一说,但是,这里想表达的是,对于性能的追求,也需要分场景,在不分场景的情况下刻意追求性能,如异常所产生的性能对系统整体影响微乎其微,这种情况下,回避代码的可维护性而去追去所谓性能,实在是不提倡。

  • 4,代码中,主体流与异常流要组织好,让代码突出主体流,更易于理解。
  • 5,了解助手函数的好处,多用助手函数。

四,写高质量函数所要了解的

  • 1,单一抽象层次原则

    • 让一个方法中,所有操作处于相同的抽象层。
  • 2,驯服深层嵌套

    • 使用卫语句
    • 重复检测条件中某一部分来简化嵌套
    • 使用break
    • if 转换为 if-then-else
    • 嵌套if 转换为 case
    • 嵌套的代码提取为子程序
  • 3,函数设计原则: 短小
  • 4,函数单一职责

    • 函数名称或者代码块的业务目标是什么
    • 函数的执行步骤,抽象层次是否相同
    • 如果有足够的行数在解决不相关的子问题,提取之
    • 每一行代码是否在为目标工作?如果不是,提取之
    • 函数的语句有副作用吗?
  • 5,函数的命名

    • 动词或者动记词短语 , 如: saveXXXXObject
    • 符合命名规则 ,如bean的get,set方法等,
    • 驼峰式命名
  • 6,好的函数名称

    • 描述代码块所干的事情,能反映出业务内容
    • 避免使用无意义,模糊,表达不清的动词, 如: run , perform ,execute , processInput等
    • 不要通过数字在区分不同子程序, 如 printUser , printUser1 ,printUser2 ,同样,使用顺序字母也不应使用。
    • 避免重复,如 Document类, Document.print 即可, 而Document.printDocument则罗嗦。 而SystemUtil.printDocument则不是。
    • 函数名称长短适宜。 (这一点,我认为,如果在迫不得已的情况下,长的比短的更合适)
    • 能描述输出结果。 如 pen.currentColor
    • 命名单词符合常规则习惯,不搞生避字等。
  • 7,关于函数的参数

    • 使用参数对象

      • 如:queryObjectByDate(Date start, Date end) 改为: queryObjectByDate(DateRange dateRange)
      • 解决数据泥团
      • 以函数作为参数
    • 保持对象完整

      • 如果函数的参数,需要从某个对象取若干个属性作为一次调用,可以直接将些对象作为参数
    • 过长的参数解决办法
    • 分解成小函数
    • 以函数作为参数
    • 引入参数对象
    • 变长参数
    • 可选参数
    • 关于参数的顺序

      • 如果有函数使用了类似的参数,就应该让这些参数顺序一致
    • 应避免以下情况

      • 将参数作为临时变量
      • 参数即作为输入,又作为输出 。 容器参数除外。
  • 8,复杂的表达式应对办法

    • 引入解释变量
    • 分解表达式
    • 引入布尔函数
    • 表驱动法
  • 9,关于循环

    • while , for 使用场景

      • for:预先知道循环次数 ,简单场景
      • while:预先不知,但是知道在什么条件下要跳出 ,复杂场景。如查有中途要跳出的情况,最好使用while
    • 一个循环只做一件事情
    • 用 {} 把循环括起来,就算循环体只有一句话
    • 循环终止的条件一定要明显
    • 不要随意修改for循环的下标,也不要滥用下标
    • 嵌套的层次不要太多,避免超过3层
    • 如查循环体内容过长,提取子函数吧。
  • 10,关于常量

    • 避免魔法值

      • 别忘了final
    • 使用类或者枚举类来替代类别码
  • 11,关于变量

    • 减少没有价值的临时变量
    • 变量的用途单一,避免多用途
    • 尽可能的减少中间结果。 解释变量除外。
    • 变量的作用域尽可能地小,存活时间尽可能地短
    • 临时变量不要远离它的业务代码

    总的来说,变量应尽可能地轻量级

  • 12,注释

    理想情况:不需要注释,代码自解释
    好代码 > 坏代码 + 好注释

    • 注释应该紧凑,精炼
    • 避免使用不明确,含糊的表达
    • 描述函数的行为要精确
    • 说明参数、返回值的含义
    • 配套有输入输出的例子
  • 13,重复代码

    • pull members/method up
    • push members/method down

想一下,IntellijIdea工具中,Refactor菜单中的功能 ,你用过几个?

五,修改遗留下的代码

首先,请做到不伤害 -- 不要让它变得更糟

你是去治疗病人,而不是去伤害病人

关于重构

1,持续进行,而不在版本发布后才想起重构。
2,小步骤进行,不要尝试硬着陆

网友评论

登录后评论
0/500
评论
fewafd
+ 关注