如果你对开发团队进行问卷，大多数人会说“我们想要可读性高的代码”。你甚至发现有些人认为可读性比功能更重要。但是，当要求人们对可读性做出定义时，他们的意见就会出现分歧。Laura Savino在Explore DDD 2018大会上的演讲就是以这个作为前提。她阐述了为什么我们想要可读性高的代码、可读性究竟意味着什么，以及什么时候必须优先考虑可读性。
Savino拥有小学法语教师的背景，后来成为iOS开发人员和导师，因此，她能够提供更多有关比较自然语言和编程语言的见解。刚开始学习新编程语言的程序员通常先学写一个基本的“Hello，world！”应用程序。同样，“Bonjour”、“Hola”或“Guten-tag”可能是学习法语、西班牙语或德语的人学会的第一个单词。
正如程序员将迅速学会“Hello，world！”，口语也会很快进入中间阶段。Savino举了一个例子，在法语课上问一个同学是否愿意在课后和你一起去喝咖啡（Voulez-vous prendreuncaféavelve moiaprèslescours？）。即使他拒绝了（Désolé，je ne peux pas prendredecaféprèslescours），在别人看来这是有史以来最无聊的谈话，但你自己却感觉飘飘然：你说了一个句子，然后有人理解它，因为你收到了适当的回应，而你了解回应是什么意思。这就像在iOS应用程序中显示数据一样——它不是那么吸引人，但当你第一次成功完成这个任务时，你的肾上腺素会飙升。
学习语言的高级阶段超越了对语法的思考。你的目标已经超越了只是相互理解，你现在需要深入细节。这时候编程语言与人类语言之间的类比开始不再奏效，或者至少需要更深入的分析。
在进行代码评审时，经常会有人说，“我无法理解这些代码”，而另一个人（可能是作者）反驳说，“但这种方式更具可读性”。Savino用这个例子来说明“可读性取决是谁在阅读代码”。让可读性变得复杂的是代码有两种不同的受众：其他开发人员和计算机。因为计算机如果无法读懂我们的代码，它们很快就会告诉我们，我们自然会基于计算机的反馈做出调整。我们承认这种偏见的存在，有时候会在代码周围加上人类可读的注释。但是，Savino警告说，“注释并不能带来具备可读性的代码”。
Savino解释了解读文本或代码与流利阅读之间的区别。她使用E. E. Cummings的诗“when serpents bargain for the right to squirm”作为例子，一个美丽而复杂的作品需要阅读多次才能真正开始理解其中的含义。当你在阅读代码时遇到不熟悉的术语时需要经历类似的过程——查找一个，然后是下一个，然后是下一个，你就像进了一个兔子洞，直到你忘记了最初想要理解的内容为止。Savino警告说，虽然可以从深刻的理解中获得快乐，但“写诗与开发软件不是一回事”。
相反，流利的阅读是一种快速而正确的理解，不会占用你的工作记忆。多年的阅读经验让你能够快速浏览文章并仍然能够理解其中的内容。Savino认为，阅读可读性高的代码也是如此。当代码很容易阅读时，大脑可以腾出一部分发现其中可能出现的问题，让代码评审更加高效。
在给出了高可读性代码为什么如此重要的原因之后，Savino探讨了如何写出高可读性代码的技术。在与语言不流利的谈话对象沟通时应该避免使用俚语，并使用明确的表达方式。在代码中，方法的命名可以用beginApp()，而不是releaseTheHounds()，并在每一步给出变量和调用结果，而不是将函数调用链接在一起。
Savino还探讨了我们的本能模式匹配能力。在抽象层面，需要使用“斜视测试”来查看代码的一般性结构，看看是否有任何异常的东西。在更低的层面，尽量避免使用看起来相似的字符和符号，包括!、I、l和1，这些可能会导致反模式匹配。最后，如果你正在做一些与众不同的东西，那就以一种可以让它从脱颖而出的命名方式。
对于作家来说，最好的建议是“了解你的受众”。Savino说，当你的受众是阅读你的代码的人时，你应该更进一步，并信任他们。当有人告诉你代码不够清晰时，相信他们，然后问他们因为缺少了哪些信息导致代码难以阅读。用他们的反馈来提高代码的可读性。
最后，Savino提到了一些可读性需要成为主要驱动因素的例子。简单地说，一段代码越重要，它的可读性就应该越高。Savino引用了美国宇航局喷气推进实验室的编码指南，该指南指出，“任务关键代码不应该只是可以辩证的，还必须是绝对正确的”。与人类沟通有关的一个更为实际的场景是火灾逃生标志，在逃离火灾时，人们不需要额外的努力看懂这些标志。
你的团队应该针对是否以及何时需要可读代码展开讨论。你的目标应该是所有团队成员都能流利地阅读代码。Savino最后鼓励每个人进行“更少的解读，更多的创造”。
