在计算通信领域，写几段人类能够理解的文字，实在比敲几行不令编译器呕吐的代码要困难得多。

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

除了一件事。

要学会阅读源代码，Luke。

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

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

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

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

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

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

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

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

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

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

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

关于译(作)者:
姚睿尧：入门级程序员，在试错中成长。（新浪微博：@大隐于微博 | 个人博客：浮游）