开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
简洁代码书写法则 - 技术翻译 - 开源中国社区

简洁代码书写法则 【已翻译100%】

英文原文:Clean Code Principles
标签: <无>
oschina 推荐于 6个月前 (共 15 段, 翻译完成于 08-04) 评论 6
收藏  
58
推荐标签: 待读

什么是简洁代码

“简洁代码”是我在写代码中一直以来遵循的一条理论。事实上,对于我来说,与其说是一种理论,不如说是一种信仰。他是这么一种理念——你的代码必须够简洁且尽可能接近于完美。如果你所写出来的代码比你所需要的多,那么多出来的那部分代码不应该存在其中。任何的多余都是不可能容忍的,而且一直以来我甚至觉得一个空格都不允许多余。你要让你的代码不仅仅是解决了问题,而是尽可能的有效率、可读性好、易维护。同样,我经常花很多额外的时间去设计我的代码。

所有的一切开始于 2001 年,当时我正在读 Andy  Hunt 和 Dave  Thomas 写的《程序员修炼之道》。读到其中如“永远不要接受一个坏了的窗口”之类的观点时,让我产生了共鸣。

txmnyzz
 翻译得不错哦!

这设想起来十分简单。想象下,你有一间房子,然后因为没有设计图来修复它,墙面开始裂开,然后越来越严重,直到房顶坍塌。或者你有一辆购物手推车,你把它遗弃在街角,然后人们开始往里面扔垃圾。很快,整个推车都将塞满垃圾直到溢出来。在以上两种情况中,如果你不设定好清楚的界限和规则,长久之后你肯定会遇到问题。我以前入职过一家新公司,那里的团队写出很多脏代码,在那里工作一点都不开心。我意识到,当人们开始变得懒惰,对自己的代码毫无责任心时,问题就会累积。结果是,每一次有更新时,他们都要花不知道多少时间去进行一次次修改。没有人需要这样的代码。

我把自己称作是实用至上的完美主义者。这意味着,一方面,在特定情况下我解决问题时,使用的方法一般是合理并且恰当的,而不是依赖于模糊的想法和理论。另一方面,我希望我的代码能够在第一次就尽可能完美,不是我喜欢浪费时间,而是因为足够节约,我知道这将在之后给我省下更多时间。

txmnyzz
 翻译得不错哦!

如何完成“简洁代码”设计

那么,该怎样创造“简洁代码”呢?首先,你不能把你的项目当做一个代码项目;你要把它想象成一个设计和计划的过程。很多开发者经常一头猛扎进代码中一顿乱敲,因为他们受到他们领导们或者其他人的要求完成尽快任务的压力。相比之下,一个具有“简洁代码”编写习惯的开发者,会尽量确保自己在开始敲代码前已经理解了问题的重点所在。想象下你正在建一栋房子,而你却打算建一个薄弱的地基,如果你之后想要扩大你的房子,你将花费更多的时间和金钱去重筑地基。这就是为什么,对我来说,程序的第一步,就是和客户方了解清楚,他需要的结果具体是什么样的。

txmnyzz
 翻译得不错哦!

如果您遵循领域模型驱动设计,那么下一步让代码简洁的方法是:创建共用语言或“领域通用语言”。 代码的用词非常重要,因为您希望您的变量名称,类名称和包名称无论谁查看代码都能理解。 现在有些开发者会说:“拜托,我们只用了一些愚蠢的名字,稍后再改。”

虽然这看起来是最快的解决办法,但是团队,甚至是编写它的开发人员,可能会迷失在这些无意义的名字中。 代码中的每个抽象词语可能会给不同的团队成员带来不同的关于项目方向的概念, 如果我考虑编写一个梨,而你考虑编写一个苹果,我们最终会得到一个无用的苹果梨混合词。

总长
 翻译得不错哦!

如果每个人都参与进来,从客户到开发人员,在设计过程中进行良好的沟通,我们就开启了这门与项目一起发展的通用的“无处不在的语言”。目标是一个完整的、可理解的程序,由整个团队编写,但看起来好像是由一个人编写的。它应该由简单的元素组合在一起,来传达复杂的思想。我们应该避免模棱两可的术语而传达不了恰当的理解。以这种方式进行沟通将有助于我们预防问题,而不是以后再解决问题。现在,我们可以确认客户想要苹果还是雪梨,最终达成客户满意的结果。在刚开始时花些时间讨论,如果可以真正帮助选择项目的进行方向 ,就可以为以后节省许多时间。

圣洁之子
 翻译得不错哦!

估算上的赌博

整洁编码的难点之一是估算你的时间表。许多开发人员害怕对他们的经理诚实,这就是为什么我认为信任你的经理是很重要的。比方说你有一种直觉,认为一个项目需要十天,但是你害怕说“十天”,所以你会想:“嗯,如果我真地很努力,我加班,如果一切顺利的话,我应该能在八天内完成这项工作。” 我称之为估算上的赌博。于是,你就定下一个时间表,走到老板或客户跟前说: “我会在八天内搞定它。”你猜怎么着?许多经理会回你一句:“我给你四天时间!” 于是,一个你认为很可能要花十天时间的项目,如果没有缺陷(bug)的话,现在变得几乎没有时间了,现在你很忙,以至于你无法顾及你本应该做到的代码整洁。

圣洁之子
 翻译得不错哦!

通常,我把一切都考虑进去。如果我觉得一个项目需要十天,我通常会告诉我的客户十五天。那不是说我一开始先花五天四处闲逛。我尽我最大的努力按我直觉的时间完成那个项目,但经常发生的是,客户改变需求,或者可能我最初的设计不可行,所以我需要那额外的五天。

对于开发人员来说,这是一件困难的事情,尤其是当你的同事声称他或她能在一半时间内完成。当然,也许他们会得到这份工作,但是,当结果是一坨屎时,你就会得到下一份工作。在一个灵活的团队里,你的老板可能会让你有额外的时间,如果你不能按时完成,但那也是在赌博。客户很少会那么宽容。永远不要赌你要花多少时间。你必须相信你自己,相信你的知识。

对我来说,做一个软件工匠就是要有一种专注的态度,对你的代码、工作和时间负责。所以,从开始讨论到最终结果,你的一个焦点应该是保持你自己的高标准,尽可能为你的客户创造最好的产品。

圣洁之子
 翻译得不错哦!

系统设计

好了,所以现在我们有了我们的远景、共同语言和时间表,我们可以开始计划我们的代码了。我做这事的方法是在白板上画方框,表示我们的系统,以及我们系统的不同组件如何在一起工作。这样做的目的是可视化我们的系统将如何运行,并讨论使组件相互作用的最高效的方法。当你发现你的设计错综复杂,就要寻找方法来简化,因为错综复杂的区域是缺陷(bug)和代码崩溃的温床。

现在,你有了自己的设计,但是你的同事呢?他开发相同系统的想法可能与你的完全不同,而这正是我们需要更多讨论的地方。在小组工作时,我一向认为开发人员应该争辩和讨论他们的系统。这有助于提高系统的效率和效用。这也有助于保持统一的代码远景,并保持高昂的团队精神,因为每个人都在一起工作。

圣洁之子
 翻译得不错哦!

我喜欢拿这些方框图作为与客户进一步沟通的机会。他们通常不懂代码,但他们理解带有商业术语注解的方框图。你可以问他们:“这是你所想的吗?” 并让他们参与这个过程。这是许多开发人员未能利用的系统设计中最强大的方面之一,因为即使是不懂代码的人,仍然能够理解设计的总体概念。

当团队之中或团队与客户之间出现分歧时,不要过于担心。分歧是一个很好的征兆,意味着需要进一步的改进或调整,应该被看作是改善结果的机会,而不是威胁。这些征兆仅仅意味着你们在达成共识之前需要多说。一个轻量级的、基于团队的开放讨论是这里的关键方法。等级扁平的公司更容易促成这种讨论。总是要尽早让客户参与讨论。有时,意见不同的原因可能是客户不晓得他们的选择会导致性能不佳、维护困难或成本高昂。所以,问他们:“我们现在真的需要这个功能吗?如果需要,我们能简化它吗?”

圣洁之子
 翻译得不错哦!

从另一方面来看,开发者经常没有意识到,一些无法抗拒的商务因素往往会导致客户把任务变得更加地复杂。客户方面经常会提出一些不必要的需求,然后开发者们就尝试满足他们。但是我相信,开发者的工作不是这样的,不要为了迎合客户而盲目地接受用户的需求,当你觉得某些需求不切实际的时候,应当主动说出来。战胜分歧,需要双方对彼此抱有足够的尊重和信任。如果你能把自我放在一边并促进这个过程,结果将会是双赢。双方都必须不断问对方问题和挑战对方观点,直到达成共识。这样一来,才能最大可能地为客户创造出真正想要的产品。

txmnyzz
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(6)
Ctrl/CMD+Enter

写这么多文字,不如直接贴代码块然后在里面注释来的直观
ericGy啦啦啦
@ericGy ericGy啦啦啦
感觉和 简洁代码,没多大关系。
写这么多文字,不如直接贴代码块然后在里面注释来的直观
遇到过这样的事情,同事用C++11优雅的花了300行实现了一个功能, 我实在看不过去了花了50行重新实现了这功能.
顶部