第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！
多年以来，在我教授的一门专业软件工程师课程中用到了这本书。这本书我反复读了十几遍，每次都有新的收获。话虽这么说，但我发现书中有一半的内容都是错误的。我希望涵盖从这本书、其他人、我的导师以及我自身的经历中学到的经验教训，但我想从怎样的代码才是“整洁的代码”说起；更准确地说，从怎样的代码不是“整洁的代码”说起。
怎样的代码不整洁？
判断代码是否整洁的问题在于，这个目标完全是主观的。如果你让七位经验丰富、功成名就的软件工程师来定义整洁的代码，那么最终他们会给你七个迥异的定义。《Clean Code》一书的第七章已经证明了这个观点。
另一方面，脏乱的代码是非常客观的。我可以编写一段代码，每位看到的工程师都同意这段代码一团糟。
这意味着从脏乱的代码到整洁的代码有一个范围，一端是客观的，而另一端不是客观的。下图简要说明了这一点。
在上图中，一组工程师对几个代码样本进行了评级。然后，将每个样本按平均分排序。我们用误差范围表示某个等级的一致度。如你所见，随着平均分的提高，评分的偏差也随之增大。
如果整洁的代码是主观的，那么我们对于编写代码还有其他更加现实的目标吗？降低代码的脏乱度算不算一个目标？
定义脏乱
在明确定义代码的脏乱之前，我们首先应该在影响代码实际用途的因素优先级上达成一致。我认为下面是其中一些重要的方面，没有特定的先后顺序。
高效：使用最少的资源（时间、内存等）来完成工作。
健壮：即便输入有错，也可以合理地处理。
交付：最小化交付时间。
正确：接收到良好的输入时，返回正确的输出。
可扩展：添加新功能的难度很小。
可运行：最小化为代码达到可运行状态付出的工作。
灵活：改变代码工作方式的难度很小。
可靠：我们很自信修改代码不会出错。
可读：将另一位工程师理解代码所需的时间降到最低。
这些都是人们在定义整洁的代码时常常讨论的方面。你可以考虑一下在你心目中这些因素的优先顺序。
虽然我说了这些方面没有特定的优先顺序，但其实则不然，上述顺序与我心目中的优先顺序正好相反。如果代码具备可读性，那么所有工程师都可以理解代码，这意味着他们可以轻松地实现其他方面。实际上，“阅读旧代码所花费的时间比例超过了10:1。每次写新代码的时候，我们都需要阅读旧代码。”如果代码易于理解，则易于测试、修改和运行。因此，也易于扩展、修复、部署和改进。最后，如果交付到实际客户的手中，则可以提高某些地方的健壮性和效率。
因此，我们的优先级可分为四层：
可读。
可靠，灵活，可运行。
可扩展，正确，交付。
健壮，高效。
每一层都服务于下一层的实现。鉴于此，我们可以将脏乱的代码定义为难以阅读的代码。
代码的可读性因人而异，因为每位开发人员的经验水平各不相同，熟悉的软件范式、编程语言、代码库、编译器、操作系统等也不尽相同。而且最重要的是，读代码的人与作者之间从来都没有完全相同的文化和词汇。我们力求做到为大多数人提供最方便阅读的代码。
Suess博士的著作《The Cat in The Hat》（戴帽子的猫）的读者数量超过了James Joyce的著作《Ulysses》（尤利西斯），也是因为这个原因。因为前者的受众范围更广，读起来更简单。当然，我们可以争论哪本杰作更伟大，但是我们不会争论哪本书的阅读难度更高。
我认为，在审阅代码这件事上，傻瓜比天才更出色（这也是为什么我认为我很擅长代码审阅）。当一个傻瓜遇到一段聪明、预料之外、有副作用、不容易懂的代码时，他们会为之苦恼，因此他们会毫不犹豫地指出这些问题。而当一个天才阅读这段代码时，他们的大脑会飞快地运转，并在短时间内消化所有的代码。尽管傻瓜遇到问题时不一定知道该如何修复，但代码审阅过程中，确定问题确实存在才是关键的第一步。
因此，傻瓜和天才都有各自的弊端。幸运的是，无论你认为自己更倾向哪一种，都可以坚持做好一件事情：不断提高自身，以及编写代码的能力。
工匠精神
没人能在学习建筑的第一天就建造出泰姬陵。无论你身处何处，眼前都有一段很长的路需要走下去。严格来讲，每个人距离完美都遥不可及。
作为一名作者，是撰写骗取点击量的文章，还是撰写有意义的文章，二者之间有本质的区别。大千世界里这两种类型的作者都不罕见，可能骗取点击量的文章确实可以获得更多的点击。但是你想成为哪一种呢？
作为一名工匠，你不必担心人们的赞美或衡量最终结果的标准，你应该为自己的全力以赴而感到自豪。此外，你还需要不断提高自己的技术力。
工匠的作品会受到同行业中其他人的称赞，而那些不懂行的人往往会忽视。工匠关心的是作品的质量，对于编写代码来说，就是代码的可读性。你的代码不一定完美，但你应该努力将脏乱度降到最低。除此之外，你应该原谅自己过去的一无所知。最重要的是，你应该向所有人学习，甚至是那些不了解你的才能的傻瓜。
速度很重要
你的产品和项目经理会很关心你的速度。关心质量是你的本职工作。一位出色的经理明白，无论从时间还是金钱上来讲，工程都是编写代码的过程中最昂贵的部分，因此优化这部分资源在金钱的角度来看也很有意义。高质量、可读性强的代码可以最大程度地减少繁琐的代码债务并提高速度。然而，更常见的是幼稚的经理只看重当前冲刺或季度冲刺的收益。
想象一下，你找了一家公司处理税务。公司就像你的经理一样，希望工作人员尽快完成尽可能多的税务评估，以确保他们可以获得最大利润。但是，如果税务专业人员的工作质量不佳，那么就让会让公司面临诉讼、声誉受损和长期失败的风险。保证工作质量，并防止这种风险是税务工作人员的责任。每个职业都是如此。律师与服务的公司，医生与医院，机械师与商店。如果你事先知道某个员工不愿意坚守工作质量，那么你还愿意雇佣他们吗？软件工程师也不例外。
工匠应该在不牺牲工作质量的情况下尽快交付产品，他们对此持有坚定的立场。所以，我们的问题是，如何在编写高质量（具有可读性）的代码和经理能够忍受的交付速度之间取得平衡？对我而言，找到最佳平衡的方法是：首先编写代码来解决和理解问题，再经过可读性的优化后，最后交付代码。通常，我知道我的代码仍有改进的空间，但是就我的技术水平而言，如果这些改进是显而易见的，那么我会在第二次修改代码时改进。而且之后我还会在每次修改代码或添加新功能时，反复改进。
编写脏乱度较低的代码
关于如何编写更好的代码，网上有大量的媒体讨论，例如书籍、博客、视频等等。通常他们都会列举你需要遵守的一系列规则。然而问题在于，这些规则之间往往是相互冲突的。很多人都认为这些规则并没有什么用，或者是可以忽视的观点。的确，在软件开发中，每个规则都可能有例外，但是不能仅仅因为你无法时时刻刻都遵循这些规则，就否定你应该尽可能地遵循它们。
有关这方面的规则有很多，我们应该从哪里开始呢？我的建议如下：
1、有简单的规则，也有复杂的规则。首先学习简单的规则。这些是你的基础，因此请务必正确理解这些简单的规则。
2、每个优先级都有各种规则，你首先应该学习可读性的规则，然而再学习第二优先的规则。
3、有些规则可以频繁使用，而有些规则仅适用于特定情况，请先学习前者。
4、有些规则是错误的。如果它与许多更简单、更重要和更实用的规则相冲突，那么可以暂时忽略。
最后，那些相互冲突的规则又当如何呢？作为技术人员，这个问题无可避免，你应该根据需要解决的问题，选择更优先的规则。
今后该怎么做？
逐步建立属于自己的一套规则，在编写代码时遵循这些规则。即便遵循这些规则不一定能够保证你写出整洁的代码，但是最起码可以降低代码的脏乱度。
原文发布时间：2020-01-17
本文作者：CSDN
