The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
有一本由罗伯特·马丁（Robert Martin）写的著名书籍叫做《Clean Code》。标题对我们所有人来说都是一个明显的呼吁：代码必须是干净的。我想象一下，就像一个厨房一样干净——没有脏盘子，地板上没有垃圾，毛巾也没有异味。根据马丁的说法，需要清理代码库中的污垢，包括冗长的方法、无描述性的变量名、紧密耦合、缺乏SOLID和SRP规范等等。阅读这本书是值得的。然而，源代码还有另一个方面。它有多清晰？
当烤箱里没有污垢时，厨房就是干净的。但是，如果烤箱的面板是用法语显示的，我就无法使用厨房。即使它非常干净，也不清晰如何使用它，这就是为什么它是无用的。
这个比喻也适用于源代码。使其干净是第一步，也是非常重要的一步，这将消除许多书籍中提到的编码反模式，包括我最喜欢的Code Complete（作者：史蒂夫·麦康奈尔）、Working Effectively With Legacy Code（作者：迈克尔·费瑟斯）和Clean Code。这是一个非常重要的步骤，但不是最重要的一步。一个有用的脏厨房比一个我无法使用的干净厨房更好，不是吗？
使代码干净，但让别人难以理解是我们大多数人会陷入的陷阱。我所说的“别人”是指从我们旁边的项目合作开发人员，到在我们都被谷歌聘用后五年后加入项目的富有想象力的初级贡献者。在这个很长的时间范围内，所有这些人都必须能够在没有任何额外帮助的情况下使用这个厨房源代码。烤箱必须说他们的语言，而不是设计者的语言。
如何做到这一点？如何确保代码是清晰的，而不仅仅是干净的？
好的，测试它。请一个项目外的人来看看你的代码，并告诉你它有多清晰。不是你的类和代码结构有多美丽——这是使其干净的原因。相反，让别人在30分钟内修复一个bug，看看他们的反应。你会意识到代码有多清晰，以及它是否说出了一个陌生人能理解的语言。
这就是可维护性的定义。如果一个陌生人能够在不到一个小时内修改你的代码和修复一个bug，那么它是可维护的。显然，干净的代码会有所帮助。但这还不够。还必须有其他东西，我不知道如何描述。实现这一点的唯一方法是让陌生人定期看到你的代码，尝试做出贡献，并在有不清晰之处时报告bug。
让你的代码开放，并鼓励程序员在出现问题时报告bug——这是实现高可维护性的最佳两种方式。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 05:10
