全文共2245字，预计学习时长7分钟

来源：Pexels

大多数代码都很糟糕，这听起来有些刺耳，不是吗？

但事实上，其中有一点是真实的。你可能已经研究过一些代码库，并认为它们是一团乱麻。

没有开发者是完美无缺的。他们所有人，不论你认为他们有多优秀，都会犯或大或小的错误。

糟糕的命名，太宏观的函数，糟糕的架构决策，重复的代码。我可以接连说出很多问题，并且你可能都见过这些错误。可能是自己看到了这些错误或是有人点明它们，或是自己有幸看到了其他开发人员的修改请求。

于是乎，小芯在本文中将和大家一起讨论如何减少代码库中的混乱，使它成为一个更优秀的代码库。

糟糕代码产生的原因

好的代码符合一些特定的标准。首先是可读性。大多数代码糟糕的原因之一是它难以阅读。

代码的可读性是至关重要的一个因素，因为该代码开发员可能不是唯一一个从事这个项目的开发人员。即使是，一年后还会记得整个代码库吗？

提高代码的可读性的方式有很多。其中之一是给变量、方法和类别赋予有意义的名称。是的，elapsedTime是一个不错的变量名，但是elapsedTimeInSeconds呢？比之前者，这才更有意义。

使用可发音的名字来说明代码库的用途，避免错误信息。知道如何给出有意义的名字可以让理解一篇代码变得更容易，这样也更容易对代码进行维护。

尽量保持函数的简短来确保可读性。这也会让函数更容易理解。百行函数包含三条命令是不可取的。为了保持简短，函数应该有且只有一项命令。

保持代码可读性的另一个好方法是限制缩进的数量。缩进过多时，代码往往难以阅读。

可以使用guard子句，而非各式嵌套的if else构造。这将有助于限制所需的缩进数量。

此外，避免使用“单行奇迹”。可读性非常重要，不应该为了使用较少的代码而牺牲可读性。

请记住，代码被阅读的频率比被编写的频率高得多。罗伯特·马丁对可读性的论述如下:

“我们一直在阅读旧代码，这是为编写新代码所做的部分努力。因此，读起来容易，写起来也容易。”——罗伯特·马丁

“你编写的代码需要最大限度地减少其他人理解代码所需的时间，即使其他人就是你自己。”——达斯汀·博斯韦尔和特雷弗·福彻

代码是可读的，但仍然不容易理解。以古怪的“单行奇迹”为例。有时可能读起来很顺畅，但依旧会误导人。

来源：Pexels

可以通过添加注释使代码更易理解。虽然好代码可能不需要注释来解释意图，但仍然可以添加注释来解释原因。

一旦项目进入维护阶段，用来解释原因的注释就变得至关重要了。这就引出了大多数代码糟糕的下一个原因——它不可维护。

开发人员或许竭尽所能使项目及时交付生产。为了在截止日期之前完成任务，开发人员会做出一些牺牲。虽然这不可取，但可以理解。

由于所做的牺牲，一个新的、重大的问题随之而来。它会耗费开发员大量的时间。一个已被更改，通常只需要几行代码就可以修复的要求，现在需耗费几个小时，因为必须重写一部分代码。

可维护性被牺牲了。

有趣的是，可维护性更容易被自身缺失所识别。粗略地说，可维护性与开发人员进行变更所需的时间以及变更会造成破坏的风险成反比。

代码中出现问题的原因之一是重复。出于某些(不好的)原因，重复代码有时会潜入代码库中。大多数情况下，重复代码会和新漏洞一起潜入代码库中。

有一种危险是，一段代码被修改了，而它的副本却被遗忘，未进行修改，导致新漏洞的出现。这种情况时常发生。如果想让代码更好，就要不惜一切代价避免重复代码。

大多数情况下，通过将代码移动到自己的函数或类中，可以修复重复的代码。然后从最初使用它的所在位置调用该函数或类。从长远来看，这是一个非常简单的解决方法，可以节省很多时间。

大多数代码糟糕的最后一个原因是它不可测试。理由非常简单。大多数程序员根本不喜欢测试。

外加一点是，太多的程序员缺乏编写适当测试的技能。或者根本不知道如何写测试。这两者的结合简直是雪上加霜。

明白这两个原因是如何相互作用的了吗？程序员如果不知道如何为自己的代码编写测试，那么可能也不知道如何编写可测试代码。然而众所周知，不测试代码是极其幼稚的行为。

但是如何使代码可测试呢？

可测试代码是以可独立验证的方式编写的代码。可测试代码接收依赖项作为输入参数，以便在测试期间可以注入假的依赖项。

将一个方法中的代码路径控制在较小的量是一个好方法，这样测试起来就简单了。如果打算编写单元测试，那么每个代码路径都应该被触及。这意味着每个代码路径可能都有自己的单元测试。

结论

来源：Pexels

“时刻要以高度紧张、认真的状态编码，就好像最终维护代码的人会是一个知道编码者住所的暴力精神病患者。”

——约翰·伍兹

写得好的代码满足一定的标准:可读、可理解、可维护、可测试。如果不符合这些标准，就有可能是糟糕的代码。

有许多方法可以提高代码的质量，其中有一个更容易实现。例如，使代码可测试会比删除重复代码要复杂得多。

只需记住，每个开发人员都会犯错误，但改正错误永远不会迟！

留言点赞关注

我们一起分享AI学习与发展的干货

如转载，请后台留言，遵守转载规范