学会阅读源代码

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

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

read the source, luke

要学会阅读源代码,Luke。

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

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

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

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

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

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

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

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

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

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

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

1 收藏 1 评论

关于作者:姚睿

姚睿:入门级程序员,在试错中成长。(新浪微博:@大隐于微博 | 个人博客:浮游) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部