本节书摘来异步社区《高效能程序员的修炼》一书中的第3章,作者: 【美】Jeff Atwood 译者: 陆其明 , 张健 责编: 陈冀康, 更多章节内容可以访问云栖社区“异步社区”公众号查看。
高效能程序员的修炼
在“沟通”这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或编译器“呕吐”的软件代码要难得多。
这就是为什么——就软件开发而言——所有的文档大概都是很差劲的。而且,由于为人写作比为机器写作要困难得多,恐怕在可预见的将来,文档还会继续差劲下去。对此,你基本上是无能为力的。
除了做一件事……
“卢克1,学着去读源代码。”
JavaScript“始终带有源代码”是一股革命性的力量,这也是我提出“阿特伍德定律2”的一个主要原因(我对这个定律至今仍然坚信不疑)。即使“查看源代码”(View Source)这个功能没有内嵌(但它完全应该有),你也应该要求查阅在你的软件之下基础源代码的权限。不管文档上面怎么说,源代码才是最终的事实,是你所能找到的最好的、最确定的、最新的“文档”。这个事实永远不会改变,所以你越早接受它,你作为一名软件开发者的境况就会越好。
我本来想针对这个问题好好地写一写,但是后来在Hacker News网站上发现Brandon Bloom已经写了一篇很棒的帖子。我自愧不如。大家去认真读一下吧,因为他解释了阅读源代码的好处,以及在何种情况下需要阅读源代码。
我大约在15岁的时候就开始在微软的平台上工作了,并且以此为业。我曾经作为一名软件开发员为微软在Visual Studio上面做集成工作。从我写下第一行Visual Basic代码后的十多年以来,我希望我可以再也不用和一个封闭的库去链接了。
使用软件和开发软件是不一样的。当你使用大多数软件的基本功能时,一般不会出现什么问题,因为这条“老”路已经被人走过很多遍了。也许其他一些人碰到了问题,并且有足够多的人把这些问题反映出来,这样会促使核心开发人员修正这些问题。而当你在开发软件的时候,你是在做一些“新”东西。而且,把东西做出来可以有很多条“路”,你会碰到之前从来没有接触过的部分、到达早已腐蚀的角落、走到那些尚未完成的试验性质的代码路径。你会遇到一些边缘情况,它们的问题是已知的,但从来没有得到真正的解决(之前只是被绕开了)。
有些时候,文档是不完整的。有些时候,它干脆就是错误的。源代码是从来不会撒谎的。对于一名有经验的程序员来说,阅读源代码通常会更快些(尤其是在你已经熟悉了软件包架构的情况下)……我现在和几个创业公司一起在一个中等规模的共享办公区域里工作。很多其他公司的首席技术官和工程师会时常跑到我们团队来寻求指导和建议。当他们带着有问题的软件过来的时候,我问他们的第一个问题通常是:“嘿,你看过源代码了吗?”
我鼓励开发人员“git clone3”他们依赖的所有源代码。起初,他们都有些害怕。“那个项目太大了。我永远也无法把问题找出来!”“我没那么聪明,看不懂那些代码。”“那些代码太难看了!简直惨不忍睹!”但是,你不必把那些代码翻个底朝天,而只需要跟着线索走。况且,如果你不能理解你所依赖的平台,你又怎么能驾驭你自己的软件呢?在大多数情况下,菜鸟程序员认为漂亮的,往往止于肤浅;而他们认为丑陋的,往往是骇客大师们所写的久经考验的产品级代码。现在,在经过一两年之后,有几个开发人员专程过来找我,感谢我当初强迫他们在别人的代码里“潜水”或者“畅游”。他们现在的技能都比以前大有长进,而且他们还感叹:真不知道过去在没有别人源代码的时候是怎么把事情做好的……
当你运营一个公司的时候,如果你的软件出了故障,你的客户不会在乎是你的失误还是Linus4的,或者是由Rails5的开发人员造成的,他们只知道是你的软件出了问题。所有其他人的软件都成了你的软件,因为他们的错误都被算到了你的头上。一旦有故障发生,你就要找出问题,并且把它修好。你需要在“应用链”的合适位置修复它,以减少风险、维护成本以及周转时间。有时候,一个快速的权变措施是最好的;而在其他时候,你得重新编译你的代码。很多时候,你可以让其他人在上游把问题修复;但是很多时候,你得自己动手解决。
真正的骇客世界里只有一个简单的事实:如果一个软件在我的机器上运行,那它就是我的软件。我要对它负责。我必须把它弄明白。从源代码开始构建是一条必须遵循的原则,而且从不例外。我必须控制我的环境,我还要控制所有我依赖的东西。
没有人是为了好玩才去读别人的代码的。见鬼了,我甚至都不愿意读我自己的代码。想着你舒服地坐在皮椅上,穿着便装,端上一杯白兰地,阅读着别人的代码来度过一个美妙的夜晚——这个念头真是荒诞至极!
但是,我们需要接触到源代码。我们必须阅读别人的代码,因为只有理解了那些代码之后,我们才能把自己的事情做好。所以,卢克,请你不要害怕阅读源代码——不管它看起来有多么可怕,也不管它会把你带向何方,跟它去吧!