当我们追踪源码时，要追踪到什么程度？

源码追踪，是所有开发工程师要迈出的一道门槛。不会源码追踪，或者不习惯于研究出色开源组件的源码，注定会限制自己的成长，也无法广泛借鉴更多的编程技巧和工程思想。不会追踪源码，就像是不会识字的文盲，没办法在海量的知识海洋中遨游与成长。

前两天看到一篇知乎热文：《你都有哪些面试时被虐的经历？》，以极其幽默的方式描述了在技术上被蹂躏的过程。究其原因，毫无疑问是基础不牢固。但为什么会基础不牢固？无非就是在研究、钻研技术时，没有打破砂锅问到底。但我们可以进一步细问，什么叫做打破砂锅问到底？要问到什么程度才叫做到底了？

这几乎就等价于，当你追踪源码时，到底要追踪到什么程度？是追踪到你当前所用框架的实现工具层？还是要追踪到系统API调用层？又或是追踪到你语言本身的实现层次？哪里是个尽头？应该到哪里才是尽头？

回顾上面那篇知乎热文，其实有很多可以琢磨的细节。如果完全以虚心学习的态度来讲，面对拷问细节的面试官，当然是要承认自己实力的不足，知耻而后勇地努力学习。但如果从另一个角度去思考，会体现出一些非常无奈的事实：我自己的工作中就用到这个程度，为什么要问到如此细节？好不容易看了一下这个feature的实现，知道调用了系统底层的某个函数，你偏偏要问，那个系统函数是如何实现的。好不容易知道那个系统函数的实现思路，你非要问，在语言层面是什么特性保证了该实现的合理性。

如此种种，到底何时是个头？我到底应该追踪源码追踪到哪里才算是一个尽头？不是我不想打破砂锅问到底，而是，要问到哪里才是所谓的底（《用于深入思考的一些小工具》）？

这当然不是计算机领域才会存在的问题，每个领域可能都会有这样一个元问题横亘在菜鸟和高手之间。理解清楚这个“底”是什么，几乎就代表了你对这个学科最基本框架的透彻理解。

对于数学来讲，这个问题其实不难解决，因为数学领域天生提供了一个最理想的“底”，叫做公理。凡是你的结论，无法归结为公理的组合，你都叫做没有问到底。任何的证明，要一步步地追踪它的命题链条，一个个命题地追踪，直到某个命题是由公理直接推导出来，否则，你必须继续去探寻这个命题的证明细节。

但即便是如此，也会有很多人在学习数学时，浅尝辄止。例如，谈论闭包时，会涉及到聚点，而聚点又和极限有关系。但很多初学者会止步于聚点这个貌似直观的概念，而无法进一步去追问，我们这里谈论的聚点，到底是什么意思。

也即是，打破砂锅问到底这件事情，存在两方面的难度，第一个是你必须界定好或者说知晓，你这里的“底”是什么。第二，你必须有意识地拷问自己，我的追问链条真的到底了吗？如果这个底，没办法由整个领域里最基本的几个结论构成，那还叫做追问到底吗？

回到刚开始的问题，当我们追踪源码时，我们的“底”是什么？而这个问题，等价于：在计算机领域，什么才是整个大厦的元操作，或者说这个体系的公理体系？我们只需要掌握那几个最小元操作的集合，就能够推演出整个信息科技大厦？如果我们能够找到这个元操作集合，那我们的“底”也就显而易见了，即，你追踪代码时必须追踪到这几个元操作，才可以停止。否则，你就必须像追踪数学的命题链那般，要进一步去研究每个操作的实现，直到某个feature是由计算机的元操作构成为止。

那么，什么是计算机的“元操作”公理体系呢？

如同探寻任何一个“最小存在集合”的问题，要理解最小的必不可少的元素，我们不妨反过来问一下自己，当什么都没有时，我会添加那些元素，来保证我要构建的产品的完整性。也即是：如果我来设计“计算机”这个产品，将会如何设计？

所谓：无需求，不设计。计算机这个产品要解决的问题是什么？或者说，计算机的产品需求是什么？如果按照图灵的可计算来考虑，计算机要解决的磅礴需求无疑是：解决一切可计算的问题。

这个需求听起来无疑是野心勃勃，无处下手。能够承载“一切”可计算问题的解决方案，几乎让你感觉只有引入“上帝”这个外援，才能够满足产品的需求。“一切”是这个需求的变量，这个变量的变化程度是如此之大，以至于我们无处下手。那么反过来，这个需求的不变量是啥？如同字面意思所言：可计算。

什么叫做“可计算”的问题？显然，就是通过“计算”能够推导出来的问题。那什么是计算呢？无疑，它就是数学中最核心的概念，函数：使用一个输入的数字，通过某种变换，吐出一个输出的数字。如此，什么是一切可计算的问题呢？就是一切可以通过“函数变换”推导出来的问题，就可以称之为可计算的问题。

（这里其实还隐形地引入了一个必不可少的前提功能：存储。因为你要接受输入的数字，对其做变化，那么中间必然需要有暂存结果的地方。就好比是笔算需要草稿纸，中间的步骤需要被存储。）

显然，下一个需要回答的问题便是：如果要描述“函数变换”，我们需要提供哪些功能？这或许需要我们再次借助一点数学知识。在数学中，其初等函数是由“基本函数”（如四则运算、三角函数、指数函数等）的有限次组合构成，也即是，有了“基本函数”，只要能够对它们进项有限次的分步操作，便能够形成一个初等函数。而数学中的非初等函数，几乎只限于符号上的推导以及逻辑上的操作。而要把它们具象为一个个可计算的实体，便只能通过初等函数的逼近，这基本上就是“计算数学”所要研究的核心。（例如，无论多么高深的偏微分方程，如果落实到最后的计算上，它必须归集为矩阵的运算，否则就是不可计算的。而如果强行要求解理论上不可计算的问题，也只能通过可计算的解法来做逼近。）

所以，这里的核心便是，有了基本的数学函数，如四则运算、三角函数、指数函数，再把它们做有限次的组合，便能够描述所有的“可计算”操作。稍微抽象一点，如果把基本函数看作是一条条的指令，那么，这些指令的有限次组合，便可以描述所有的计算问题。

再根据计算领域的Böhm-Jacopini定理，任何复杂的指令集组合，都可以归结为三种操作：基本指令操作、条件跳转、循环。而无疑，条件跳转、循环，也可以抽象成“指令操作”。也即是，只要提供了基本的数学指令集，条件跳转、循环指令集，我们便能够描述我们的“计算”行为。

（再一次的，既然是指令集，这同样隐含了“存储”指令集这个大前提。“存储”和“计算”是密不可分的。并且，如果按照这里的“指令集”描述计算行为的思考方式，functional programming中“把函数当做数据”的思想也就自然而然地出现了。为什么说作为动词的“function”可以被当做data来看待？因为它被归结为了一堆指令集data的组合啊:=)！）

回头考察我们最开始的需求“解决一切可计算的问题”，我们所设计的产品，计算机，只需要提供指令集的操作，以及它所隐含的“存储”功能，便可以描述所有的计算问题，便能够承载所有可计算问题的。对应到现代计算机，那便是“cpu+内存”的自然组合。

讨论到这里，似乎已经将需求全部满足了。但如果进一步考虑“解决一切可计算的问题”这个需求本身，其实还有一点缺陷，就是计算和存储，可以承载问题的解决方式，可是，问题从哪里来呢？这有点像是，你有一颗充满智慧的大脑，具备解决复杂问题的能力，但是，如果没有眼睛、四肢、神经系统，你的这个“问题解决器”就成了一个自闭的一无是处的黑盒了。

所以，这里的问题是什么呢？就是你只具备解决问题的能力是不行的，你还必须有同外界交互（即吸收问题、突出解决方案）的能力。这便是I/O（input, output，输入输出的能力）这一模块的不可或缺性。有了I/O的能力，你所设计的计算机产品，便能够得到最大限度的可扩展化，是满足“一切”可计算问题的变量部分的重要元素。无论你的问题源自汽车引擎的参数调试，还是源自商业物流的最优调度，又或者源自图像视频的编辑，只要它们可以归集为“可计算问题”，便能够通过I/O模块，接入到计算机中去处理。于是，“一切”形形色色的问题，都可以通过I/O接入到你设计的这个小盒子中得到解决。这非常像人对问题的处理方式：一切问题，通过五官、四肢的感知，将信息发送给大脑。大脑经过神奇的思考（即计算），便能够输出解决方案。

如此，我们便得到了计算机的元操作公理体系，仅需要三部分：

• 计算
• 存储
• I/O

这个体系简直漂亮得令人难以置信！而上面所讨论的这个关于计算机的需求设计成果，便是大名鼎鼎的冯·诺依曼架构体系。

回到我们这篇文章的标题，当我们追踪源码时，要追踪到什么程度？答案很简单，你必须追踪到这段代码，仅涉及“CPU基本指令集的操作、内存存储的分配、I/O protocol接口调用”这几个操作的组合时，你便可以说，我的代码就追踪于此了，我算是打破砂锅问到底了。

---

如果你喜欢我的文章或分享，请长按下面的二维码关注我的微信公众号，谢谢！