如何阅读源代码

文章一：

学会阅读源代码

在计算通信领域，写几段使人类同胞能够理解的文字，实在比敲几行不会使编译器或者解释器呕吐的软件代码要困难得多。

这就是为什么每当涉及到代码，几乎所有文档都弱爆了。因为写东西给人看，比写给机器看难得多，在可以预见的未来，文档将一直弱下去，而对此你无能为力。除了一件事。

要学会阅读源代码，Luke。

JavaScript中“源代码包含一切”的变革性力量，是我提出——并一直信奉的——Atwood定律。尽管“查看源代码”没有被内置（却完全应该内置），你应该为自己的栈要求查看相关源代码。无论文档里怎么说，源代码才是最终真相，才是你所能找到的最好的、最新的并且是最权威的文档，这永远是事实。所以，你越早承认这一点，你就越能够成为一个富裕的软件开发者。

关于这一点，我曾经有一个整体的条目准备去写，后来我发现了Brandon Bloom投递在Hacker News上一个主题中的一篇杰出的文章。请认真阅读，因为他解释了阅读源代码的好处，和在什么情况下你需要阅读源代码，远比我解释得清楚：

15岁时，我开始在微软平台上从事专业工作，我作为微软的一名开发者，做一些Visual Studio的整合性工作。在我写下第一行Visual Basic代码十多年后，我希望再也不要去链接一个封闭的库。

使用软件与编写软件不同，如果你还在使用大多数软件的基本功能，那就已经落后了，其他人已经遇到问题并且许多人将问题积极提出，以此促使核心贡献者们纠正 问题。然而编写软件是一个创造的过程，而且有许多方法去做，你会遇到未使用的比特、生锈的角落以及未完成的试验代码路径；你会遇到已知被破坏的边界条件却 在正常运行。

有些时候文档并不完备，有时甚至是错误的，而源代码从不说谎。对于一个有经验的开发者，阅读源代码的速度通常会更快……特别是当你已经对包的结构很熟悉 时。我同一些创业者们在一个中等规模的协作空间中工作，很多其他CTO和工程师们偶尔会来找我们团队进行咨询。当人们报告他们堆栈中存在的问题时，我通常问他们的第一个问题是：“嗯，你读过源代码了吗？”

我鼓励开发者把他们依赖的任何东西都进行git clone。起初，他们都很担心，“工程太大了，我不可能找到它！”或者“我不够聪明，理解不了”亦或者“代码写的太丑了！我是在不想再看它”。但你不必把整个代码都搜寻一遍，只需遵循线索。如果你不能理解下层的平台，如何去弄懂自己的软件？多数时候，没有经验的开发者认为的比较好看的东西都是些表象，他们认为 难看的，则是编程高手写的久经沙场、产品级别的代码。一两年后，两个开发者找到我，感谢我曾强迫他们在自己的代码海洋中沉浮。他们的技术愈发精湛，并且很好奇当初在没有源代码的情况下自己是如何做完每件事情的。

当你经营一家公司时，如果你的软件有bug，你的客户不会去关心这是否是Linus或其他哪个Rails开发者的错，他们只知道你的软件有bug了，这时每个人的软件都变成了我的软件，因为他们的bug就是我的bug；当一些东西出错时，你需要找出哪里坏了，并修好它们，你得在栈的最佳点处修复它们，以此降低风险、节约成本并争取时间；有时，有快速的解决方案当然是好事。有时，你却需要重新编译。通常情况，你会请上游部门的人来解决，而其实通常你都得自己解 决。

● 封闭软件商店会有两个选择：乞求别人宽宏大量，或是想办法解决问题。
● 较弱开发者的开源商店往往按照封闭软件商店的做法。
● 老牌商店会慢慢的养蓄必要的“肌肉”，来维持自己的“叉子”和“补丁”诸如此类的东西。

真正的黑客们达成了一个共识：在我的机器上运行，就是我的软件，我会对它负责，我必须弄懂它；从源代码创建是规则而不是例外；我必须控制我的环境，我必须控制我的依赖。

读别人的代码没有人会感觉愉悦。而且我TM甚至不喜欢读自己的代码。能够安顿下来深陷皮革沙发中，穿着吸烟夹克（译者注：男士晚间便服），端一杯白兰地，一边阅读某人写的代码，就这样度过一个美妙的夜晚，这种想法是荒谬的。

但我们需要查看源代码。我们必须阅读他人的代码，因为要完成工作，我们必须先弄懂它。因此，不要害怕读源代码，Luke，随它带你去任何地方，无论它看起来多么可怖。

本文转自：伯乐在线
原文作者：Jeff Atwood    本文由  翻译并投稿于伯乐在线。

文章二(部分)

微软资深软件工程师：阅读代码真的很难

        首先，我同意你的看法，几乎很少有人能读代码但不会写代码。这不像自然书面语或口语，理解他人的意思并不需要去理解他们为什么要那样说。比如，如果我说：

“写代码有两种方式：一种严格且详细，另一种模糊且草率。前者生成简洁分层的婚礼蛋糕，后者却是意大利面条。”

        上面这句话产生一个平衡且幽默的效果，但即使听众和读者不理解我使用“零照应”和“并列句”这样的文字技巧，也会理解我要说的意思。但是说到代码，既要从代码本身中理解代码作者的意图，又要理解代码产生的预计效果，这两者都极为重要。

    如何调试不是我写的代码？

        这取决于我的目的。如果我只是因为一个bug，而深挖一段具体的代码，我会在调试器中逐步跟踪所有代码，写下我“走过”的调用分支，记录下哪些方法是特定数据结构的“生产者”，哪些方法是“消费者”；我也会仔细盯着输出窗口，查看出现的有用信息；还要打开异常捕捉器，因为异常通常是问题所在。设置断点；我会记录所有和我上面建议相反的地方，因为这些东西很可能误导了我。

如果我想在理解一段代码后修改它，我通常是从代码头部开始，或者先查找公共方法。我要知道类是如何实现的，它是如何扩展的，它的作用，它是如何嵌入整个代码中的？我会尽力理解这些东西后，才去了解这些特定部分（代码）是如何实现的。这耗时虽更长些，但如果你准备改动复杂代码，你应当那样做。

本文转自：伯乐在线
原文作者：Eric Lippert  译者:黄利民

文章三

如何阅读大型代码库？

Casey问我：“对于新手，有什么有针对性的诀窍来阅读大型代码库吗？”

碰巧，我认为这是一个非常好的问题。我觉得想要成为一个优秀的开发者，阅读代码库并弄清清楚内部是怎么回事的能力非常重要。在你的职业生涯中你会中途加入一个现有的项目并被要求迅速融入进去。或者，甚至更难，会有一个项目丢给你让你自己一个人搞清楚。

最坏的情景就是你被带入一个项目，要你替换掉让工程运行失败的“那些肆无忌惮的*杂种”，并且让工程运行起来。不过更常见的情景是你被要求维护一个已经离职的员工写的代码库。最后，当然，如果你用了任何开源的项目，很大的可能是被要求“你可以扩展它让它也能做这个功能吗？”亦或者你只是好奇。

尤其是新手程序员，我强烈建议阅读代码库，看看以下我是怎么做的，然后你需要实际的去阅读代码。

当我接触到新的代码库时，我常常忽略文档和表面的细节。目的是摒弃先入为主的关于它怎么运行的想法。我试图从文件结构上找出项目的结构。仅仅这个就能告诉你很多，我常常试图找出它的结构。这是整个系统的核心吗？它是怎么分割的？等等。

之后我会找到最底层的代码然后开始阅读。我常常用字典序来读。找到一个文件，读完它，然后读下一个文件。我尽量记录下来关于这些东西是如何连接在一起的（你可以在博客里找到关于记笔记的例子），但我做的最多的找到对这个代码的感觉。有很多代码常常是项目风格的一部分，比如预处理检查，日志记录，抓取错误等等。你可以先了解这部分内容，之后就可以忽略它们阅读有趣的部分。

我通常不在某一点上阅读太深，我会试图宏观的找到感觉。比如：这个文件通过调用Y和Z返回了X，但在这个点上阅读每一个细节对我来讲并不真的重要。哦对了，我还记录笔记，很多笔记。往往它们不是真的笔记而更像是问题清单，在这里我理解的越多，加入的问题和写入的回答也就更多。在阅读完我能找到的最底层代码之后，我会做一个纵向的比较。这是最让我能弄清楚事情是如何布局和工作的。这就意味着下一次我来看这部分的时候，对于代码结构我会有更好的想法。

接下来，我会找有意思的部分。系统当中对我有意思的部分而不是被我束之高阁的部分。

这部分内容很多，但其实要做的并不多。我仅仅是通读一遍代码首先找到结构，之后我会认真研读独一无二的部分并找出他们是如何写的。

在这期间，尤其是遇到难点的时候，我会试图寻找任何文档（只要有的话）。对于这一点，我应当首先知道代码是如何组织的，这样我才能更快的阅读文档。

本文转自：伯乐在线
原文作者：  译者:孑良