👧🏿 👨‍💼 🐌 2020年的“清洁法规”是什么？ 🌈 💃🏿 🥊

^{“干净的代码”和干净的猫}

不会为开发人员提供麻烦，让我们来讨论一下代码的干净度：例如，丹·阿布拉莫夫（Dan Abramov ）的帖子“再见，干净的代码”最近引起了轰动。

但是同时，“干净代码”的概念还没有一个明确的定义。关于这个问题的主要书籍是“干净的代码”，罗伯特“鲍勃叔叔”马丁在那儿立即宣布：“有多少程序员，那么多定义”。但是，他由此得出的结论并不是“谈论它是没有用的”，而是得出结论“值得比较不同的定义”。因此，他在书中引用了几位杰出的程序员关于什么是干净代码的观点。

对我们来说变得很有趣：到2020年，人类对干净代码的想法保持不变，或者自本书发行以来，它们是否有所改变？不同的IT专家的意见是否不同：也许后退者从一个角度看一切，而测试者从另一个角度看？

4月，鲍勃叔叔将飞往圣彼得堡在我们的三个会议上讲话，它们的方向分别是三个不同的方向（关于.NET开发，关于测试以及关于JavaScript）。因此，我们问了这些会议的几位发言人，他们用什么干净的代码来比较2020年行业专家的观点。

并且由于该主题是无聊的，因此可以肯定的是，你们当中的任何一个都不会同意。在这种情况下，请在评论中争论，这也很有趣！

UPD: , . , . - . . 13 , .

DotNext

John是Stack Overflow的传奇人物，《 C＃in Depth》的作者，也是地球上最著名的捐助者之一。他给了我们这个定义：

“对我来说，从实现的角度来看，干净的代码是无聊的代码。他唯一的惊喜是他有多少没有惊喜。我必须感觉到，“是的，我可以写这篇文章”，即使我真的做不到，因为它的设计多么出色。

如果正确选择了抽象，则实现是自然派生的。理想情况下，这种抽象也应该感到简单和明显-尽管实际上，将其抽象到这种状态可能需要花费数小时，数周，数月的反思和实验。

所提到的缺乏惊奇之处后来继续使用：当我使用设计良好的API编写代码时，我的代码也变得明显而乏味。”

安德烈·阿金申（Andrey Akinshin）

DotNext的访问者不需要介绍Andrei，但是对于其他内容，我们将告诉您，他以其在IDE 骑士，BenchmarkDotNet库，生动的报告和“ Pro .NET Benchmarking” 一书上的工作而闻名。

当我们问到他对干净代码的看法时，Andrei提到了他的两个老文章：“完美的代码和实际项目”和“评论或不评论”。我们从那里为您选择了几段，可能有人会提出争论：

“我喜欢完美的代码。毕竟，这不仅是编写程序的正确方法，而且是一门真正的艺术。通过阅读一份好清单，我和阅读一本好书一样多。设计大型项目的架构并不比设计大型建筑物的架构容易，而且如果运作良好，结果也同样漂亮。有时，它使我着迷于如何完美地交织设计模式以创建完美的软件系统。当所有方法绝对如此简单明了时，我称赞它对细节的关注，以至于它声称是完美代码的经典示例。

但是，a，所有这些出色的事物都被残酷的现实和真实的项目所打破。如果我们谈论的是生产项目，那么用户不在乎您的代码有多漂亮，体系结构有多好，他们关心的是项目可以正常运行。但是我仍然认为，无论如何，您应该努力正确地写作，只是不应该有狂热主义。”

迪伦·贝蒂

Habrachitateli可以在他关于遗留代码工作的周到生动的报告中记住Dylan的话：对于Habr，我们进行了解码。当我们向Dylan寻求有关干净代码的知识时，他撰写了如此详尽和周到的文章，并至少在另一篇文章中发表了这一观点：

“对我而言，“干净代码”的概念已经远远超出了阅读罗伯特·马丁（Robert Martin）书的人们的范围。我与许多开发人员进行了交谈，他们听到了“干净的代码”一词，但没有读过这本书。我什至在一个杂谈中遇到了他们：“这里的一切都很好，但是您能稍微打扫一下吗？” -如果不清楚“纯”在此特定上下文中的含义，那么这样的请求可能会很烦人。

在英语中，经常会发现一些单词-“干净”，“整洁”，“有条理”，“整洁”-对于以英语为母语的我来说，它们的含义都略有不同。我认为考虑这些词与软件开发有关的一些含义很有用。

想象一下，例如一家餐馆的厨房。在这种情况下，“干净”一词将具有非常具体的含义。一切都经过清洗，消毒，没有生食等引起感染的威胁。

但这并不意味着所有内容都井井有条。如果您曾经尝试与朋友做饭或在Airbnb上租的公寓里做饭，那您就会知道，当事情变得不对劲时，它会令人讨厌。洗碗精在自助餐中，您希望在其中看到锅，而大蒜压榨器通常不清楚在哪里。是的，一切都很干净-不会有人威胁要在这间厨房里煮熟的食物-但是在这种条件下工作很烦人。

现在想象一下一个木工车间。在这个地方，灰尘也可能会引起问题，但是这里您对“清洁度”的定义与厨房不同。您可以清洁凿子直到它开始闪闪发光，但是您仍然不太可能用它切香肠。因此，“干净”一词可能非常主观。

但是对我来说，“整洁”和“有条理”这样的词在“干净”效果不太理想的情况下起作用。 “有组织”是指某人已经仔细考虑过如何布置特定工作场所的要素，而“整洁”是指这些要素确实存在于分配给他们的地方。俗话说：“万事都有，万事都有。”

也许在代码的情况下，我们应该将“干净”，“整洁”和“有组织”这三个概念视为。“清洁”意味着您查看了代码库的组件-方法，函数，接口-并没有理由担心。在命名时要遵守惯例；变量和方法的名称编写正确无误；缩进和方括号等细节遵循单一样式；无论您在哪里看，都会看到有证据表明，从根本上讲，这是由对业务认真的人经营的。这与“肮脏的代码”相反，在“肮脏的代码”中，名称，不合适的文件名中需要使用许多错字，花括号和缩进。当您在诸如ReSharper之类的程序中调用代码清理工具时，这些问题已经神奇地修复了。

“有组织”-关于建筑。这是关于您如何进入不熟悉的代码库并在期望看到它们的地方找到东西的方法。接口和域边界有助于而不是干扰；命名的方法和变量不仅从语言的角度正确命名，而且还反映了与您合作的企业的单一语言。

和“整洁”是要尊重当地的习惯......一个代码库中，你可以找到正确的东西在自己的地方，即使特定的组织模式是不是在那一刻你很清楚。

我认为，当他们谈论争取“干净代码”的斗争时，这通常意味着所有这三个方面。但是将目标设置为完全“干净的代码”，尤其是在处理复杂的旧项目时，可能是一个令人生畏的前景。对于我们所有人来说，更深入地思考并找出“干净代码”的哪些组件将真正使我们当前正在研究的项目受益将是有用的。”

海森堡

这是“不仅针对测试人员的测试会议”：它是测试与开发的交集。因此，它的许多发言者立即了解了这两个世界的细节。

伊万·克鲁托夫（Ivan Krutov）和安娜·切尔尼雪娃（Anna Chernysheva）

伊万（Ivan）和安娜（Anna）在不同的公司工作，但有一些东西使他们团结在一起：他们都对硒很了解。我们同时与他们交谈，因此得到了一个联合定义：

Ivan：“对我而言，最简单的干净代码定义是无需注释即可理解的代码，即“自我记录”。带有乱七八糟的注释，试图解释它的功能的代码不是纯粹的代码。”

安娜：“在我看来：这是您可以快速找出，修复错误，轻松扩展，补充代码的代码。”

伊万：“您也可以说这是一个“您不会感到羞耻的代码”。通常，他们说，如果您查看六个月前编写的代码并且不感到害怕，那么您就没有开发。事实证明，您的代码每年都应该变得更加干净。”

塞巴斯蒂安·达什纳（Sebastian Dashner）

Sebastian是IBM的首席Java开发倡导者，通常可以在Java会议上看到。但是，由于他现在要飞往Heisenbug，我们在测试环境中向他询问了干净的代码，他回答说：

“根据我的经验，代码的质量不仅对于生产代码很重要，对于我们的测试也很重要。在测试中，干净的代码，正确的抽象和委托常常被忽略，这导致您无法支持测试代码。当我们重构生产代码并更改其行为时，很明显我们是否在建模和实施测试方面做得很好。”

安德烈·拉什尼科夫（Andrey Lushnikov）

Andrey正在开发一种浏览器自动化工具Playwright，我们最近对此进行了介绍。他的定义原来是最简洁的：

“干净的代码是愚蠢的，非常容易理解的代码。而且哑气效果更好。”

亚历山德拉（Alexandra Svatikova）

亚历山德拉（Alexandra）是Odnoklassniki的信息安全专家，他“从Java的开发人员开始从事IT工作，但走了错误的路”。它的定义原来是：

“纯代码具有三个属性：另一个开发人员可以轻松阅读和理解它，较小的改进需要相应的努力，并且可以预见特定更改的效果。

实际上，这意味着代码的结构简洁，简洁，遵循所编写语言的公认惯例，不包含隐式依赖关系或副作用，并且已通过测试覆盖。”

神圣的

安德烈·梅利霍夫（Andrey Melikhov）

许多人都以安德烈（Devshakhta）项目而闻名。毫不奇怪，一个不断在Devshacht播客中表达思想的人清楚地表明了自己的立场：

“罗伯特叔叔”马丁带着三本主要著作（“清洁法规”，“清洁编码人员”和“清洁建筑”），在我看来，他正在努力为自己回答一些问题：应该写谁，什么以及如何写。有人可以争论他的某些结论的正确性，但这是无可争辩的-这些书都是基于丰富的个人经验和常识而编写的。在这个想法的框架内，我可以说一个干净的代码是由一个人编写的代码，这个人在生活中遇到了很多陷阱，并且在这个痛苦的过程中学会了以谨慎的步态走路，从而避免了这种情况。

您可能对这个人的风格不满意，但是如果您跟随他，您肯定会保持完整。您可以采用这种样式并对其进行回收，使其为您自己方便。或者，您可以拼命潜入河中，填满自己的球果，发展自己的风格，而其余的人则难以置信地看着你，在老同志的监督下前进。

纯代码是易于阅读，易于维护和易于扩展的代码。这三个方面为面对不断变化的外部需求必须生存多年的应用程序奠定了坚实的基础。也就是说，我们在大型公司中编写的此类应用程序“

亚历山德拉（Alexandra Kalinina）

亚历山德拉（Alexandra）是HolyJS程序委员会的成员，她在编程方面拥有丰富的经验-尽管她不曾在Heisenbug任职，但她也了解测试的第一手资料（单元，集成，E2E，B2B）。这是她的文字：

“清洁代码现在是一个简单的概念，但很难理解。在我看来，遵循以下规则可以得到简洁的代码：

-每个单独的代码段都应该能够独立于其他代码段进行缩放或增长/改进，但同时保留原始思想/与其他代码段集成（SOLID可以为您提供很多帮助，并且以及“以后必须做出的所有决定都必须在以后做出”的规则。
-该代码应作为一本有趣的书阅读，并带有易于理解的典型名称和名称。例如，如果您决定写一个故事，那么它很可能具有典型的结构，如简介，情节，高潮和结局。即使您是唯一从事项目工作的人，无论选择哪种体系结构，语言或框架，您都应该可以随时轻松阅读代码。
-代码应具有清晰的结构。那些。应该理解该代码或代码在项目中的原因。
“应该从业务角度证明每一行代码的合理性”

尼科洛·里鲍多（NicolòRibaudo）

Nicolo还是一名学生，后来成为Babel编译器的主要开发人员之一（我们已经分别询问了他）。他的版本原来是这样的：

“干净的代码是可以很容易地分为小的原子组件的代码。

代码原子''是可能的，具有独立含义并且不必依赖于周围环境的最小指令集：变量和操作的名称具有足够的描述性，因此读者无需在脑海中分配额外的内存来存储其值和可能的修改，以及有必要查看代码中的其他地方以了解此“原子”的结果的含义。原子越小，越容易理解代码的作用。

无论使用哪种编程语言或范例，代码都可以保持简洁：原子可以实现为小的对象，函数，甚至可以实现为没有语法隔离的小段代码。”

结论

最后，在收集意见后，我们向鲍勃叔叔本人展示了这些意见，并询问他是否想说些什么。答案是：

“我完全支持上述评论员。我只想补充一下迈克尔·费瑟斯（Michael Feathers）曾经说过的一句话：“干净的代码总是看起来像是一个在乎的人写的。”

他的结论听起来很友好。但是干净的代码是一个值得商topic的话题，以致于当你们当中的一个人点头时，其他人可能正在着火，感觉像这样：

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
“这几个字”可以使你的颠簸变得充实，而其他人则看上去很困惑。但是，当您填充视锥细胞并了解其原因时，就会出现所有最好的创新方法，而不仅仅是遵循旧书！”

UPD 3月12日：尽管Bob叔叔无法飞往我们，但我们在圣彼得堡的会议（面向.NET开发人员，测试人员和JavaScript开发人员）不太可能对纯净代码提出异议。在会议站点上-始终是程序的最新版本。请继续关注并订阅我们的新闻通讯-我们每周一次将讨论更改。

2020年的“清洁法规”是什么？