[Engineering] 编程哲学（四）：把控间接性

计算机领域有句名言：“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。但是过多的间接性反而会造成不好的影响，所以人们进行了这样补充，

...except for the problem of too many layers of indirection.[1]

间接性指的是，为了达成某个目的，我们可以先做另外一件事情，然后再绕过来解决原始的问题。间接性在编程工作中很常见，实际在不知不觉中，我们已经使用了它。

计算过程是存在于计算机里的一类抽象事物，在其演化进程中，这些过程会去操作一些被称为数据的抽象事物。人们创建出一些称为程序的规则模式，以指导这类过程的进行。从作用上看，就像是我们在通过自己的写作魔力去控制计算机里的精灵似的。[2]

可见，程序符号不同于它们所操纵的计算过程，编写程序是间接性的一种体现，程序只是软件功能的一种符号表示。我们应该选取合适的符号，用以描述目标系统的软件功能。

在数学史上，区分符号以及对符号的解释，却花费了很长时间。人们总是不由自主的把符号解释为日常生活中熟悉的概念。

这是整个十九世纪数学的最深刻的教训之一。[3]

我们经常处于一种表达能力受限而不自知的状态。为了得到编程语言相关的种种商业好处，经常把自己局限在某个特定编程语言范围之内。我们只用这种语言去“描述”心中想做的“事情”，结果我们能“描述”的“事情”，就慢慢局限在了该语言善于“描述”的“事情”范围之中了。

除此之外，写出易读的代码，显然和写作水平有关，好的表达方式，可以把长篇大论平白直叙的“流水账”，改造成结构清晰发人深省的“文学作品”。因此，我们应该多从文学作品中学习经验，训练自己怎样把事情说清楚，以及在每个层面上把问题展开成什么样的细节程度。只有在这种情况下，封装信息和隐藏细节才突然有了意义。

重复未必是有问题的，重复的描述细节才有问题。某些代码显得无比冗余啰嗦，我们才想到要把它们放在更为细节的层次上。通常我们会先去构建一些粒度较大的“砖块”，再用这些“砖块”去搭建主流程，简化主流程的描述方式。

然而，过多的细节层次也是不恰当的，它增加了我们的描述复杂度。在大型项目中，这些“砖块”本身也会包含很多的细节，由更小的“砖块”组成。阅读代码的人，必须经常在不同的层次中上下跳跃，才能理解我们到底想要表达什么。

这时候，识别出可复用的代码才是关键。通过分析问题本身的数学结构，或者理解项目相关的业务背景，我们可以看到具有逻辑完整性的模式和工具。把它们提取出去独立放在其他的地方，可以帮助我们减少当前项目的描述层次，使之扁平化。