查看原文
其他

“整洁代码根本就是个骗局!”

Chad Befus CSDN 2020-02-17

怎样的代码才是整洁的代码,而怎样的代码不是呢?——事实上,整洁的代码就是一个弥天大谎,没有人会写整洁的代码。

作者 | Chad Befus

译者 | 弯月,责编 | 郭芮

出品 | CSDN(ID:CSDNnews)

以下为译文:

我对《Clean Code》(代码整洁之道)这本书又爱又恨。
多年以来,在我教授的一门专业软件工程师课程中用到了这本书。这本书我反复读了十几遍,每次都有新的收获。话虽这么说,但我发现书中有一半的内容都是错误的。我希望涵盖从这本书、其他人、我的导师以及我自身的经历中学到的经验教训,但我想从怎样的代码才是“整洁的代码”说起;更准确地说,从怎样的代码不是“整洁的代码”说起。

怎样的代码不整洁?

判断代码是否整洁的问题在于,这个目标完全是主观的。如果你让七位经验丰富、功成名就的软件工程师来定义整洁的代码,那么最终他们会给你七个迥异的定义。《Clean Code》一书的第七章已经证明了这个观点。
另一方面,脏乱的代码是非常客观的。我可以编写一段代码,每位看到的工程师都同意这段代码一团糟。
这意味着从脏乱的代码到整洁的代码有一个范围,一端是客观的,而另一端不是客观的。下图简要说明了这一点。

在上图中,一组工程师对几个代码样本进行了评级。然后,将每个样本按平均分排序。我们用误差范围表示某个等级的一致度。如你所见,随着平均分的提高,评分的偏差也随之增大。
如果整洁的代码是主观的,那么我们对于编写代码还有其他更加现实的目标吗?降低代码的脏乱度算不算一个目标?

定义脏乱

在明确定义代码的脏乱之前,我们首先应该在影响代码实际用途的因素优先级上达成一致。我认为下面是其中一些重要的方面,没有特定的先后顺序。
  • 高效:使用最少的资源(时间、内存等)来完成工作。

  • 健壮:即便输入有错,也可以合理地处理。

  • 交付:最小化交付时间。

  • 正确:接收到良好的输入时,返回正确的输出。

  • 可扩展:添加新功能的难度很小。

  • 可运行:最小化为代码达到可运行状态付出的工作。

  • 灵活:改变代码工作方式的难度很小。

  • 可靠:我们很自信修改代码不会出错。

  • 可读:将另一位工程师理解代码所需的时间降到最低。

这些都是人们在定义整洁的代码时常常讨论的方面。你可以考虑一下在你心目中这些因素的优先顺序。

虽然我说了这些方面没有特定的优先顺序,但其实则不然,上述顺序与我心目中的优先顺序正好相反。如果代码具备可读性,那么所有工程师都可以理解代码,这意味着他们可以轻松地实现其他方面。实际上,“阅读旧代码所花费的时间比例超过了10:1。每次写新代码的时候,我们都需要阅读旧代码。”如果代码易于理解,则易于测试、修改和运行。因此,也易于扩展、修复、部署和改进。最后,如果交付到实际客户的手中,则可以提高某些地方的健壮性和效率。
因此,我们的优先级可分为四层:
可读。
可靠,灵活,可运行。
可扩展,正确,交付。
健壮,高效。
每一层都服务于下一层的实现。鉴于此,我们可以将脏乱的代码定义为难以阅读的代码。
代码的可读性因人而异,因为每位开发人员的经验水平各不相同,熟悉的软件范式、编程语言、代码库、编译器、操作系统等也不尽相同。而且最重要的是,读代码的人与作者之间从来都没有完全相同的文化和词汇。我们力求做到为大多数人提供最方便阅读的代码。
Suess博士的著作《The Cat in The Hat》(戴帽子的猫)的读者数量超过了James Joyce的著作《Ulysses》(尤利西斯),也是因为这个原因。因为前者的受众范围更广,读起来更简单。当然,我们可以争论哪本杰作更伟大,但是我们不会争论哪本书的阅读难度更高。
我认为,在审阅代码这件事上,傻瓜比天才更出色(这也是为什么我认为我很擅长代码审阅)。当一个傻瓜遇到一段聪明、预料之外、有副作用、不容易懂的代码时,他们会为之苦恼,因此他们会毫不犹豫地指出这些问题。而当一个天才阅读这段代码时,他们的大脑会飞快地运转,并在短时间内消化所有的代码。尽管傻瓜遇到问题时不一定知道该如何修复,但代码审阅过程中,确定问题确实存在才是关键的第一步。

因此,傻瓜和天才都有各自的弊端。幸运的是,无论你认为自己更倾向哪一种,都可以坚持做好一件事情:不断提高自身,以及编写代码的能力。

工匠精神

没人能在学习建筑的第一天就建造出泰姬陵。无论你身处何处,眼前都有一段很长的路需要走下去。严格来讲,每个人距离完美都遥不可及。
作为一名作者,是撰写骗取点击量的文章,还是撰写有意义的文章,二者之间有本质的区别。大千世界里这两种类型的作者都不罕见,可能骗取点击量的文章确实可以获得更多的点击。但是你想成为哪一种呢?
作为一名工匠,你不必担心人们的赞美或衡量最终结果的标准,你应该为自己的全力以赴而感到自豪。此外,你还需要不断提高自己的技术力。
工匠的作品会受到同行业中其他人的称赞,而那些不懂行的人往往会忽视。工匠关心的是作品的质量,对于编写代码来说,就是代码的可读性。你的代码不一定完美,但你应该努力将脏乱度降到最低。除此之外,你应该原谅自己过去的一无所知。最重要的是,你应该向所有人学习,甚至是那些不了解你的才能的傻瓜。

速度很重要

你的产品和项目经理会很关心你的速度。关心质量是你的本职工作。一位出色的经理明白,无论从时间还是金钱上来讲,工程都是编写代码的过程中最昂贵的部分,因此优化这部分资源在金钱的角度来看也很有意义。高质量、可读性强的代码可以最大程度地减少繁琐的代码债务并提高速度。然而,更常见的是幼稚的经理只看重当前冲刺或季度冲刺的收益。
想象一下,你找了一家公司处理税务。公司就像你的经理一样,希望工作人员尽快完成尽可能多的税务评估,以确保他们可以获得最大利润。但是,如果税务专业人员的工作质量不佳,那么就让会让公司面临诉讼、声誉受损和长期失败的风险。保证工作质量,并防止这种风险是税务工作人员的责任。每个职业都是如此。律师与服务的公司,医生与医院,机械师与商店。如果你事先知道某个员工不愿意坚守工作质量,那么你还愿意雇佣他们吗?软件工程师也不例外。
工匠应该在不牺牲工作质量的情况下尽快交付产品,他们对此持有坚定的立场。所以,我们的问题是,如何在编写高质量(具有可读性)的代码和经理能够忍受的交付速度之间取得平衡?对我而言,找到最佳平衡的方法是:首先编写代码来解决和理解问题,再经过可读性的优化后,最后交付代码。通常,我知道我的代码仍有改进的空间,但是就我的技术水平而言,如果这些改进是显而易见的,那么我会在第二次修改代码时改进。而且之后我还会在每次修改代码或添加新功能时,反复改进。

编写脏乱度较低的代码

关于如何编写更好的代码,网上有大量的媒体讨论,例如书籍、博客、视频等等。通常他们都会列举你需要遵守的一系列规则。然而问题在于,这些规则之间往往是相互冲突的。很多人都认为这些规则并没有什么用,或者是可以忽视的观点。的确,在软件开发中,每个规则都可能有例外,但是不能仅仅因为你无法时时刻刻都遵循这些规则,就否定你应该尽可能地遵循它们。
有关这方面的规则有很多,我们应该从哪里开始呢?我的建议如下:
1、有简单的规则,也有复杂的规则。首先学习简单的规则。这些是你的基础,因此请务必正确理解这些简单的规则。
2、每个优先级都有各种规则,你首先应该学习可读性的规则,然而再学习第二优先的规则。
3、有些规则可以频繁使用,而有些规则仅适用于特定情况,请先学习前者。
4、有些规则是错误的。如果它与许多更简单、更重要和更实用的规则相冲突,那么可以暂时忽略。
最后,那些相互冲突的规则又当如何呢?作为技术人员,这个问题无可避免,你应该根据需要解决的问题,选择更优先的规则。

今后该怎么做?

逐步建立属于自己的一套规则,在编写代码时遵循这些规则。即便遵循这些规则不一定能够保证你写出整洁的代码,但是最起码可以降低代码的脏乱度。
原文:https://hackernoon.com/less-dirty-code-2c27321g
本文为 CSDN 翻译,转载请注明来源出处。

热 文 推 荐 

为什么 k8s 在阿里能成功?| 问底中国 IT 技术演进
☞微信付费阅读支付宝可用,iOS抽成30%;苹果安卓充电器或统一;UOS 20发布 | 极客头条
☞如何实现自动化前端开发?
阿里将开源进行到底!

斯坦福博士退学,在 3 个领域改变世界,科技狂人马斯克的巅峰之路

滴滴章文嵩:一个人的20年开源热情和国内互联网开源运动

详谈ARM架构与ARM内核发展史

BSV魔幻爆拉背后:CSW称拿到自证中本聪的关键证据

你点的每个“在看”,我都认真当成了喜欢


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存