在一系列的实验中，研究者们开始发现在「困难」（或「不流利」）和「认知」之间的关系。他们为两组人员提供了相同的测试，一组以易读的(直观的)格式，而另一组以困难的(不流利)格式。在所有他们实施的实验中，格式不流利的组大体上得分更高。这背后的理论就是人类会默认依赖自动的、不费力的、简单的系统去推理。但是如果事情是背道而驰的，或者很难去理解的，我们就会切换到一种更深层的、仔细的、有分析性的模式去思考。
我一直在想这是如何影响编程的。编程是一个智力上的挑战任务，但幸运的是，我们发明了工具去使它变得可管理了。我发现在一定程度上，一个直观的的、简单属性的语言、框架、或者类库可能会开始产生一些负面效果。从个人经历和指导新人的过程中，我发现当我们使用一些允许我们去顺着思维的方向推理的工具时，任何我们遇到困难的时候，我们都会感觉到自己做错了。尽管我们已经有了解决困难的必需技能，我们通常会开始质疑、重查我们的工作。我们会提出问题，去寻找相关框架的最佳实践，而不是用我们自己的方法去解决问题。有关这点的最经典的问题就是Stack overflow上的问题：『如何用jQuery去做X』，或者回答『用jQuery的某个插件去做X』，X可能是从基础算法到websockets的任何事情。
框架的未知领域
当我们使用一个框架的时候，特定的一类问题将会很好解决。如果我们待在框架创造出来的空间里，程序设计会变得很直观。我们可以这称作框架的直观空间。另一方面，我们把框架涉及不到的空间成为框架的未知领域(nagative space)。未知领域并不一定是框架的缺点，它只是不在框架所考虑要解决的范围之内。然而，它已经将程序员置于直觉空间中很久了。如果程序员发现自己在未知领域，就会感觉到无从下手。
当初学程序员发现他们自己在未知领域的时候，他们经常会向类库的作者求助，并让他们再次回到直观空间里。这就是一些流行框架会产生一个插件和扩展的生态系统来扩展他的直观空间的原因。如果这使得程序员更加有生产力，那么这看起来并不是本质上的错误。然而，它可能会无意间产生消极的影响：
- 增加了程序员对生态系统的类库作者的依赖性
- 受到技术冲击的时候将架构决策完全归结于类库
- 传播了错误的思想：程序应该永远是直观的
开发者和类库作者相互依赖
我应该首先说明，这是一个技术上错误的分歧。所有程序员在任何程序设计的讨论中都扮演着两种角色。你可能会开发产品的业务逻辑然后转而去构建一个通用的抽象库来帮助你在你的代码库里进行复用。然而，我注意到在开源项目里，人们的行为倾向于使分歧看起来真实
我发现在开源项目里能够成功的最简单的方式就是去将框架的未知领域变为直观空间。换句话说，就是写插件和扩展。当框架变得更加流行，大量的开发者(通常是初学者)将会开始抱怨在这个框架里实现X有多么困难(正如我们看到的，X可能完全不相关)。现在，在这样一个商业化的世界里，开源是极具竞争性的。一旦一个开源项目结局了许多人的直观上的问题，许多人就会转变立场。这成为了错误理念的传播器：一个程序员应该花所有的时间在直观空间编程
结论
我认为改正这个问题的根本要从教育中落实。当某人开始学习编程的初期，我们的文化就趋向于强调对工具的依赖。我收到了许多有志气的程序员的提问，关于什么是最好的学习工具或语言。这基本上总是一个不成熟的问题。我过去常常给出这样的回答：”取决于你要构建什么”或者”选择一个对初学者友好的社区”或者”投资一个成长中的语言”。我认为所有这些都是好的答案，但是这在程序员的早期学习过程中并不重要。当你学习编程的本质的时候，都是一样的。此外，这些答案使得依赖工具的文化成为可能。
代码复用，类库、分享和开源对于软件工程师来说都非常重要，但是我们应该谨慎，不能让人们相信”编程就应该像把东西粘起来一样简单”的思想。事实上，这几天当我感觉到事情有点太简单的时候，我都会对此非常怀疑。如果编程这样简单的话，它早就已经被自动化了。
转载请注明出处
