与其说阅读代码如同读书，不如说如读棋谱
从小阅读计算机编程书籍，
大师们就教育我，
写代码如同写书，
代码是写给人看的，
不是写给机器看的，
所以一定要保证有优良的可读性。
具体的来说就是要做到：
遵守命名规范；
清晰的注释；
最大限度的代码复用。
最好呢，
还有要有完善的文档。
但是，书与程序还有有些不同。
不同的地方在于程序是非空间线性结构。
对于书来讲，
我无论从哪开始翻起，内容都是连续的。
尽管对于一些情节紧凑的小说来讲，
可能从中间开始看，仍然不明所以，
但不影响叙事的线性顺序。
从物理空间的角度看，作者一定是希望读者从上到下，从左到右，从前一页到后一页的顺序来阅读。
而代码不是这样子。
假如我们将一个系统的代码全部打印出来。
连怎么排序都是个问题。
最简单粗放的方式就是按照文件名排列（排序A）。
如果我们按照读书的方式来阅读排序A的结果，
除了超人之外很难能读懂这个系统到底要做什么。
（可以设想下排在前几本的程序会是什么，按这个顺序读代码会是一场灾难）
对于书来讲，最开始一定会是目录和前言。
那我们作一个代码文件的或者函数的目录，并且索引出来。
然后写一个介绍系统功能的前言（排序A改）。
这样可以通过类似于翻新华字典的方式，
来阅读我们的代码。
但我们还是不知道该从何读起。（先找到MAIN()是个明智的做法，但有些时候并没有Main）
一个故事，一定有一个开头，
一个代码，一定有一个入口。
代码的内容的组织方式与故事不同。
代码在物理空间上不是线性的，
而是在时间上线性。
从代码的入口开始，可能下一行的内容要跳到别的代码里，
然后再跳进另一本代码里，
然后出现了一个分支，
再次进入另一本代码
。。。。。。。。
终于在翻了大半本书之后，
跳回了第一页。
然后下一行，
再次跳遍了大半本书。
内容之间只有前后，
没有绝对的下一页一定和这一页相关，
甚至下一行与这一行的相关。
其实，如果看过棋谱的话，就会知道，
代码的这种特性，
与棋谱很像。
棋谱，
有两种记法。
一种是按照着棋的顺序，以纯文字描述。
如象棋棋谱中的 马五平七，车三进四。
一种是绘成图，然后每一着上写着步数。
读者自行按照图中的数字脑补在不同时点棋盘上的样子。
当然，代码是无法如同第二种技法那样具象化的。
所以，阅读代码的最好的方式并不是按照文件和上下文的物理顺序来读，
而是按照时间顺序来组织。
以后可以做个工具以静态分析的方式将程序的调用顺序列出来，
以达到debug单步执行的效果。
