原文作者：Jeff Atwood 在计算通信领域，写几段使人类同胞能够理解的文字，实在比敲几行不会使编译器或者解释器呕吐的软件代码要困难得多。 这就是为什么每当涉及到代码，几乎所有文档都弱爆了。因为写东西给人看，比写给机器看难得多，在可以预见的未来，文档将一直弱下去，而对此你无能为力。除了一件事。
要学会阅读源代码，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 本文由@姚睿尧 翻译并投稿于伯乐在线。如果您也愿意分享一篇自己的原创/译文，可以 从这里开始哦。 |
