阅读更多

30顶
3踩

编程语言

翻译新闻 编写好代码的10条戒律

2011-07-18 15:36 by 见习编辑 jobbole 评论(23) 有14775人浏览

  1. DRY: 不要重复你自己(Don’t repeat yourself)

  DRY是一条最容易理解但又是相对比较难以应用的原则。它是指当你在两处或者更多的地方发现相似代码时,我们应当把它们抽象成一个新的函数,在之前重复的地方调用新的函数并带上适当的参数。

  DRY也许是最普遍的一条编程原则,我从未发现一个开发人员认为编写重复的代码是件好事。但是我发现一些开发人员在编写单元测试时忘记了这条原则,例如:设想一下你改变了一个类的接口,之前已经为这个类编写了很多的单元测试,如果你没有应用DRY原则,这时你需要手动去修改所有使用这个类接口的调用,来与每一个测试实例的新签名匹配。


  2. 编写短小的函数/方法

  有三个非常好的理由,选择编写短小的函数。

  • 1. 代码会更容易阅读。
  • 2. 代码会更容易重用(短小的函数更容易产生松耦合)。
  • 3. 代码会更易于测试。


  编者注:松耦合:在软件领域中,“耦合”一般指软件组件之间的依赖程度。耦合度松的软件会有较好的扩展性。


  3. 给类、函数和变量使用好的命名

  直接使用其他开发者的代码而不需要阅读说明文档,没有什么比这更好的事情了,因为代码中的类名、函数名已经能够告诉我们所有需要的信息。所以,采用这种方法,每次在为你的代码中任何元素进行命名的之前请花上几秒钟(思考),这会让大家的生活变得更轻松。


  4. 为每个类分配正确的职责

  一个类只承担一个职责(单一权责),听起来和有些人知道的SOLID原则很相似,但是这里不是指任意的职责,而是正确的职责。所以,如果我们要设计一个顾客类,我们不会给它创建一个销售的行为,我们只会让它处理所有与一个客户相关的数据。

  编者注:SOLID:面向对象设计的五项原则 (是SRP单一职责原则、OCP开闭原则、LSP李式代换原则、ISP依赖反转原则和 DIP接口分离原则,首字符的缩写)。


  5. 保持代码的条理性

  代码条理性分两个层次

  • 物理上的条理性:无论你采用了哪种结构,包、命名空间、文件夹等等,用一种更容易并且凭直觉就能找到代码存放在哪里的方式来组织你编写的类。
  • 逻辑上的条理性:不论逻辑上从属关系如何,(只要有逻辑从属关系)类都应该能够互相访问彼此的成员变量,但是如果从属于不同的逻辑结构就应当只能通过接口来访问。这种逻辑分组通常会被实现成(逻辑)层、服务等。


  6. 编写很多的单元测试

  测试越多越好,它们是所有代码变动的安全保证,我们会在将来的某一天需要运行这些测试代码。


  7. 尽早且经常地重构代码(Refactor often and sooner)

  软件开发是一个持续发现的过程,为了编写保持与新增/改变的需求匹配的高质量代码,随着开发的进行,重构代码是必不可少的。由于重构是一项带有风险的任务,需要有两个主要的前提条件,来避免由于重构给系统引入新的错误。

  • 1. 编写很多的单元测试
  • 2. 每一次重构的幅度要比较小。在开发软件过程中,开始重构2000行代码,3个小时以后发现所有的代码都不能工作,并且导致问题的原因无从查找,因此需要恢复到最初版本,几乎没什么事能比这更让人抓狂了。


  8. 注释是恶魔

  这条特殊戒律有一点争议,我们大多数人学到的是“注释是一个好的习惯”,并且在一段晦涩的代码中有一段注释会比仅仅只有代码好的多,这里我的观点是:给晦涩的代码加注释还不如仅仅留下代码,只需要重构这段代码直到它变得可读为止。(编注:当然了,除了作者说的这种类型的代码,在其他情况下,还是得添加必要的注释,这不仅方便自己日后查看,更有利于后来者维护,请参阅《提高代码可读性的10个注释技巧 》一文。


  9. 要面向接口编程,不要面向实现编程(Code to an interface, not to an implementation)

  这是一条经典的原则,面向接口编程会让我们从实现的细节中解放出来,我们只要定义一个协议,并且依据协议调用定义的操作,期望(对方,即被调用的代码)能把实际的实现或者运行时态的实现传递给我们的代码。


  10. 对代码进行复查

  我们都会犯错误,没有什么能比请别人对我们代码做一个非正式快速复查更好的办法来查找错误了。最好不要等到代码都完成以后再复查,当某些重要部分的代码完成后,或者离上一次复查相隔几天之后,就进行复查。


  原文:Alberto Gutierrez   翻译:伯乐在线 敏捷翻译 - 唐尤华

来自: www.jobbole.com
30
3
评论 共 23 条 请登录后发表评论
23 楼 雪飘寒 2011-11-09 11:11
aystnd 写道
LubinJava 写道
什么是面向对象编程,
在天朝,一切都是面向现实编程.

文章是讨论如何写好代码,你非要扯上其他的,有牢骚不要在这里抱怨,抱怨只能说明你这人不是个纯粹做技术的。


看了一下,理论上都是正确的,很好,不过实际中就不是这么回事了,什么东西都要联系实际。
人家怎么怎么叫扯到别的上面了,人家说的是实话,是实际,总比空谈这些理论好吧。
22 楼 aystnd 2011-07-25 11:08
LubinJava 写道
什么是面向对象编程,
在天朝,一切都是面向现实编程.

文章是讨论如何写好代码,你非要扯上其他的,有牢骚不要在这里抱怨,抱怨只能说明你这人不是个纯粹做技术的。
21 楼 taolei0628 2011-07-23 10:55
我很少写注释,但我认为这是我做得不好的地方。
代码能写到不用注释就能读懂?太不现实了。

引用8楼的看法:
第8条有什么想不通的,干净的代码无需太多注释,每一个类名,每一个函数名,每一个对齐的格式,本身就是最好的注释。只有垃圾代码,才靠大量注释来解释其含义,并且难改,也容易出bug,更严重的是:有时候你代码改了,注释没改,这样反而会引起误解!

程序写的烂不是注释的错。按你的理解,JDK的源代码就是烂的不能再烂的代码了。
20 楼 hellolaojiang 2011-07-20 13:19
LubinJava 写道
什么是面向对象编程,
在天朝,一切都是面向现实编程.

   
19 楼 LubinJava 2011-07-20 09:55
什么是面向对象编程,
在天朝,一切都是面向现实编程.
18 楼 lvhjean 2011-07-20 08:13
同意 17楼 的观点 工作中 一大部分都是做 面向现实的
17 楼 boyuliu 2011-07-19 21:42
公司大部分代码都是面向现实, 每天被细节所引发出的问题而煎熬着
16 楼 别惹Java 2011-07-19 20:08
单元测试不怎么写
15 楼 jiushiyouke 2011-07-19 18:29
《重构》+《代码整洁之道》的总结
14 楼 walkintojava 2011-07-19 17:37
注释可以用方法名,类名, 以及代码本来来代替。
13 楼 lyzhanghai 2011-07-19 17:03
骨之灵魂 写道
说的不错。
第8条的意思是 当你认为加上注释才能让别人理解这段代码时,说明这段代码需要重构了。

《重构》的那本书上就是这么写的
12 楼 geminiyellow 2011-07-19 15:30
spring
11 楼 骨之灵魂 2011-07-19 12:37
说的不错。
第8条的意思是 当你认为加上注释才能让别人理解这段代码时,说明这段代码需要重构了。
10 楼 parchingo 2011-07-19 11:29
作为一个初学者来说,我的代码总是有点乱,想到哪里就写到哪里,看了这东西后相当有感触,谢谢分享!
9 楼 微雨心晴 2011-07-19 10:23
第八条严格来讲是正确的!但这个正确是有条件的!初学者一定要注意被误导!
完整解释在我的微博上,就不写了:http://weibo.com/sharedata
8 楼 niva 2011-07-19 10:16
第8条有什么想不通的,干净的代码无需太多注释,每一个类名,每一个函数名,每一个对齐的格式,本身就是最好的注释。只有垃圾代码,才靠大量注释来解释其含义,并且难改,也容易出bug,更严重的是:有时候你代码改了,注释没改,这样反而会引起误解!
7 楼 smilebomb 2011-07-19 09:49
唉,第8条,让人想不通,本人持有相反的意见
6 楼 yjc2020 2011-07-19 09:16
注释写的明白就有用,否则没神马用
5 楼 liu.anxin 2011-07-19 08:46
看过一些人写的注释, 敷衍的那种. 看老半天不知道注释上写的到底什么意思, 具体的还得去看代码.
4 楼 allenny 2011-07-19 03:15
不同意注释那一条

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Global site tag (gtag.js) - Google Analytics