短期可用性不等同于长期可用性

在设计几乎任何一段代码或其他功能时，经常会出现可用性问题。大多数时候，这些讨论进行得很顺利，但也有一些时候出现了相当大的分歧。甚至可能有两个人主张完全相反的方法，都声称他们的方法更好是因为可用性。这似乎是一个悖论，但仔细研究后我们会发现，这并不是因为没有一样东西叫做可用性的简单原因。什么是可用的，什么是不可用的，取决于一大堆不同的东西。举个例子，让我们设想一下，有一个软件工具可以做一些事情。它具体做什么并不重要，但让我们假设它需要是可配置和可定制的。一种经典的方法是创建一个小核心，然后为最终用户添加一种配置语言。语言可能是图灵完整的，可能是设计出来的，或者当人们根据需要添加新功能时，它可能会意外地发展成图灵完整。最常见的情况是，这是通过添加到Reduce样板中的一些宏扩展功能来实现的。

也许这类工具最著名的例子就是Make。本质上，它只是一个DAG解算器，您只需在Makefile中直接编写shell脚本片段，就可以拥有任意功能。潜在的想法是为开发人员提供他们需要的工具来解决他们自己的特殊问题。这些类型的意外编程环境出人意料地常见。有人告诉我，某大型软件公司在网络上提供服务，对他们公司内部有多少自创的图灵完全配置语言进行了调查。我从来没有设法从他们那里得到一个实际的数字，这应该会告诉你，真正的答案可能是太多了。

尽管如此，Make还是经受住了时间的考验，就像许多其他使用这种方法的项目一样。就像生活中的一切一样，这个建筑也有它的缺点。主要的部分可以分成两部分，第一部分是这样的：

尽管这种方法很容易上手，而且您可以让它做任何事情(毕竟这就是图灵完备性所做的事情)，但它很快就会达到性能上限。随着项目规模的增长，更改配置和添加新功能变得越来越乏味。这就是众所周知的图灵油井，在这里一切皆有可能，但没有一件事是容易的。

在实践中，这种情况似乎经常发生。有人会说，每一次。要理解其中的原因，我们需要记住Jussi的程序员法则：

程序员的问题是，如果你给他们机会，他们就会开始编程。

另一种说法是，如果你给程序员解决他们自己的问题的可能性，他们将会解决他们自己的地狱问题。这些类型的架构奏响了经典Unix黑客灵魂的琴弦。没有愚蠢的限制，相反，程序员负责并可以微调解决方案，以匹配他们独特的雪花项目的确切细节和细节。环境最初不是为一般编程而设计的，这一事实并不是威慑，而是功绩的象征。毕竟，让软件做一些它最初设计不是要做的事情，才是最初的黑客伦理的全部意义所在。这意味着每个项目最终都会以不同的方式解决相同的常见问题。这在多个项目上违反了干原则。尽管每个单独的项目只解决一次任何问题，但在全球范围内，它们被解决了数十次，甚至数百次。最糟糕的是，所有这些解决方案都不能协同工作。武断地制定项目，试图将一个项目作为另一个项目的子项目，这是行不通的，只会导致泪水。

另一种方法是创建某种类型的配置界面，该界面特定于手头的问题，但可防止最终用户执行任意操作。看起来是这样的。

主要要注意的是，在开始时，这种方法客观上是更糟糕的。如果您一开始就开始使用其中一个，则完全有可能它不能解决您的问题，而且您也不能自己使其工作，您需要更改系统(通常是通过编写和发送拉请求)。这给使用现有的可调整系统带来了巨大的压力，因为即使它可能会更糟，至少它可以工作。

然而，一旦这种方法走出了它的死亡谷，并支持了用户需要的大多数东西，那么网络效应就会发挥作用，一切都会改变。事实证明，感觉到的雪花与实际的雪花有很大的不同。事实上，对于大多数项目来说，大多数问题几乎都是一样的，这些问题的解决方案大多令人厌烦。一旦有了现成的解决方案，人们就会非常乐意使用它，这意味着您在一个项目中的任何经验都可以立即转移到使用相同工具的所有其他项目中。此外，由于一般编程已被阻止，您可以相当肯定[1]没有牛仔程序员仅仅因为他们更了解或者更有可能没有阅读文档而意识到他们想要的功能已经存在而去重新实现基本功能。