如果您喜欢这篇文章，可以在我自己的博客上阅读此文章。
像很多人一样，我有一种宠物编程范例，我喜欢适应各种代码库和使用的语言。
我想稍微标准化一下，并与世界分享。 它被称为“专注于明确性的最小共享状态编程” （我不太擅长命名）。 当我心中的应用统计学家开始教我道：“嘿，我可以尝试做一个小实验”时，我正在考虑如何向全世界和我自己证明它的价值。
所以我做到了，我写了两段代码来做同一件事，这是一个相当简单的任务。 一个是功能性的，另一个是我的宠物范例编写的。 我创建了一个网站，可以为参与者提供一个或另一个代码段，并请他们解释（在几段中）代码的作用。
代码很简单，任何能读代码的人只要摸了一下脑子，就能弄清代码的作用。 确实，在手动检查大约20％的答案（随机选择）后，没有一个是错误的。
但是，答案本身并不是我真正关心的数据。 相反，我要监视的是，人们花了多长时间得出答案，多少人在阅读完任务后放弃了却什么也没写。
我的想法是：“如果一种编程风格确实易于阅读，那意味着程序员应该有一个更轻松的时间将其转化为大脑中的抽象概念，然后转化为单词”。 因此，您可以通过查看某人能以多快的速度理解一个“简单”的代码，而不是查看他是否能够理解一个大型的代码库（其中包含许多问题）来部分评估编程风格的困难。
令我惊讶和不满的是，该研究未能证明我的假设。 在数百个答案的样本中，人们解释我的宠物范例代码与以纯功能样式编写的代码的速度有多大差异（在删除了一些可疑数据并且z得分> 5类异常值之后） ） 。
因此，我对统计心理学的不佳尝试破坏了我推广和勾勒这一新范式的计划。
但是，这让我开始思考如何“验证”所使用的编程范例。
在寻找某些样式为何以及在某些地方优先于其他样式的原因时，人们提出了几乎无限数量的博客文章，reddit参数，白皮书，演讲，轶事等。
但是，目前还没有任何实际的研究支持这一点。
我们为备份某种范例所做的很多工作都是在哲学上加油。
相反，我们应该做的是通过“科学”（阅读：实验）这一重要视角来审视它的好处。
（思想）实验
前端开发现在是一个热门领域。 让我们假设在工具，样式和语法方面的两个“领先”范例是用Typescript编写的Angular和用ES6编写的React + Redux。
我并不是说它们是两种主要样式，因为我对浏览器技术不是最新的。 但是，为了争辩，请假设它们是。
这两套工具之间没有可量化的差异。 当然，我听到一群人在尖叫，世界上有很多不同：
- Blah导致更好的隔离，可以改善模块化。
- Bleh导致界面更简洁，从而使代码易于阅读。
- Blax帮助我们在浏览器之间获得更统一的性能，从而带来更可预测的用户体验。
- Blerg表示从X的角度来看状态是不可变的，这使得对Y的修改更容易进行。
- Blif将帮助新人们更快地学习“做事方式”，而不是学习“做事方式”。
- …等等，等等，等等，
正如我之前所说，您可以抒情地探讨为什么您的范例更好，而相反的范例是万恶之源。
