《高效能程序员的修炼》一学会读源代码

学会读源代码

高效能程序员的修炼
在“沟通”这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或编译器“呕吐”的软件代码要难得多。

这就是为什么——就软件开发而言——所有的文档大概都是很差劲的。而且,由于为人写作比为机器写作要困难得多,恐怕在可预见的将来,文档还会继续差劲下去。对此,你基本上是无能为力的。

除了做一件事……

“卢克1,学着去读源代码。”

JavaScript“始终带有源代码”是一股革命性的力量,这也是我提出“阿特伍德定律2”的一个主要原因(我对这个定律至今仍然坚信不疑)。即使“查看源代码”(View Source)这个功能没有内嵌(但它完全应该有),你也应该要求查阅在你的软件之下基础源代码的权限。不管文档上面怎么说,源代码才是最终的事实,是你所能找到的最好的、最确定的、最新的“文档”。这个事实永远不会改变,所以你越早接受它,你作为一名软件开发者的境况就会越好。

我本来想针对这个问题好好地写一写,但是后来在Hacker News网站上发现Brandon Bloom已经写了一篇很棒的帖子。我自愧不如。大家去认真读一下吧,因为他解释了阅读源代码的好处,以及在何种情况下需要阅读源代码。

我大约在15岁的时候就开始在微软的平台上工作了,并且以此为业。我曾经作为一名软件开发员为微软在Visual Studio上面做集成工作。从我写下第一行Visual Basic代码后的十多年以来,我希望我可以再也不用和一个封闭的库去链接了。

使用软件和开发软件是不一样的。当你使用大多数软件的基本功能时,一般不会出现什么问题,因为这条“老”路已经被人走过很多遍了。也许其他一些人碰到了问题,并且有足够多的人把这些问题反映出来,这样会促使核心开发人员修正这些问题。而当你在开发软件的时候,你是在做一些“新”东西。而且,把东西做出来可以有很多条“路”,你会碰到之前从来没有接触过的部分、到达早已腐蚀的角落、走到那些尚未完成的试验性质的代码路径。你会遇到一些边缘情况,它们的问题是已知的,但从来没有得到真正的解决(之前只是被绕开了)。

有些时候,文档是不完整的。有些时候,它干脆就是错误的。源代码是从来不会撒谎的。对于一名有经验的程序员来说,阅读源代码通常会更快些(尤其是在你已经熟悉了软件包架构的情况下)……我现在和几个创业公司一起在一个中等规模的共享办公区域里工作。很多其他公司的首席技术官和工程师会时常跑到我们团队来寻求指导和建议。当他们带着有问题的软件过来的时候,我问他们的第一个问题通常是:“嘿,你看过源代码了吗?”

我鼓励开发人员“git clone3”他们依赖的所有源代码。起初,他们都有些害怕。“那个项目太大了。我永远也无法把问题找出来!”“我没那么聪明,看不懂那些代码。”“那些代码太难看了!简直惨不忍睹!”但是,你不必把那些代码翻个底朝天,而只需要跟着线索走。况且,如果你不能理解你所依赖的平台,你又怎么能驾驭你自己的软件呢?在大多数情况下,菜鸟程序员认为漂亮的,往往止于肤浅;而他们认为丑陋的,往往是骇客大师们所写的久经考验的产品级代码。现在,在经过一两年之后,有几个开发人员专程过来找我,感谢我当初强迫他们在别人的代码里“潜水”或者“畅游”。他们现在的技能都比以前大有长进,而且他们还感叹:真不知道过去在没有别人源代码的时候是怎么把事情做好的……

当你运营一个公司的时候,如果你的软件出了故障,你的客户不会在乎是你的失误还是Linus4的,或者是由Rails5的开发人员造成的,他们只知道是你的软件出了问题。所有其他人的软件都成了你的软件,因为他们的错误都被算到了你的头上。一旦有故障发生,你就要找出问题,并且把它修好。你需要在“应用链”的合适位置修复它,以减少风险、维护成本以及周转时间。有时候,一个快速的权变措施是最好的;而在其他时候,你得重新编译你的代码。很多时候,你可以让其他人在上游把问题修复;但是很多时候,你得自己动手解决。

  • 处理封闭软件的问题有两个选择:乞求他们的慷慨救援,或者采用变通方案。
  • 对于开源软件,如果他们的开发者不给力,建议像处理封闭软件的问题那样进行处理。
  • 老到一些的软件商家倾向于慢慢培养他们维护分支、补丁以及处理其他琐碎事务的能力。

真正的骇客世界里只有一个简单的事实:如果一个软件在我的机器上运行,那它就是我的软件。我要对它负责。我必须把它弄明白。从源代码开始构建是一条必须遵循的原则,而且从不例外。我必须控制我的环境,我还要控制所有我依赖的东西。

没有人是为了好玩才去读别人的代码的。见鬼了,我甚至都不愿意读我自己的代码。想着你舒服地坐在皮椅上,穿着便装,端上一杯白兰地,阅读着别人的代码来度过一个美妙的夜晚——这个念头真是荒诞至极!

但是,我们需要接触到源代码。我们必须阅读别人的代码,因为只有理解了那些代码之后,我们才能把自己的事情做好。所以,卢克,请你不要害怕阅读源代码——不管它看起来有多么可怕,也不管它会把你带向何方,跟它去吧!

时间: 2024-09-13 03:29:24

《高效能程序员的修炼》一学会读源代码的相关文章

读书笔记--《高效能程序员的修炼》

        初次邂逅......        最近小编抽空看了一本书,书的名字叫做<高效能程序员的修炼>,从这本书的名字就能看出来,软件开发远不只是写代码那么简单,你要学会的是高效能的工作,这让小编想到了去年读过的一本书<高效能人士的七个习惯>,有兴趣的小伙伴可以看看哦,受益匪浅,<高效能程序员的修炼>这本书从人文角度而非技术角度去阐释了作为一个程序员,应该具备的基本素质,所以小编在看这本书的过程中,感到非常的有共鸣,通俗易懂,又很贴近小逼啊工作和生活中的实际,

《高效能程序员的修炼》一导读

译者序 高效能程序员的修炼出版社的冀康一开始来找我谈翻译这本书的时候,我的第一反应是:这兄弟真是不知道我现在有多忙!我每天要处理200多封邮件:在资源有限的情况下经常要同时带6-7个项目,而且每个项目的交付计划都很紧,压力很大:每天起码工作12个小时,有时候还要熬夜跟美国同事开会:周六基本上也是工作状态--我哪里还有空来翻译书?! 后来,当我了解到这本书的作者是Stack Overflow网站的创始人Jeff Atwood,还有书的内容实际上就是从作者的博客网站Coding Horror精选而来

《高效能程序员的修炼》一第一条法则:永远都是你的错

第一条法则:永远都是你的错 高效能程序员的修炼作者在Twitter上发的一条短讯: "在怨天尤人之前,我们应该先自我反省.努力把自身的问题解决了." 12:22 PM – 2012-5-30 你应该知道那种感觉.我们所有人都曾碰到过这样的事情:已经盯着代码看了无数遍,但还是没有发现任何问题.然而,有个故障或者错误始终挥之不去.于是你开始怀疑,可能是你开发程序所用的那台机器出了问题,也可能是操作系统的问题,或者是你使用的工具和库出了问题.肯定是它们的原因! 然而,无论你多么绝望,都不要往

《高效能程序员的修炼》一向橡皮鸭求助

向橡皮鸭求助 高效能程序员的修炼 在Stack Exchange上,我们坚持要求提出问题的人需要在自己的问题上多下些功夫,而且我们在这方面有些偏执.那就是说,当你开始要提问题的时候,你应该: 用足够多的细节来描述发生的状况,这样我们可以顺着你的描述继续研究下去.即使在你所在的特定领域里我们并不是专家,你也要向我们提供必要的背景情况,这样我们可以了解到底发生了什么事情. 告诉我们你为什么需要知道答案.你怎么会出现在这里?是闲来无事的好奇,还是在某个项目里遇到了障碍?我们不是要求你长篇大论地讲生活故

《高效能程序员的修炼》一如何培养写作习惯

如何培养写作习惯 高效能程序员的修炼 我得忏悔一下:程序员同胞们,从某种程度上来说,我创办的Stack Overflow网站"耍"了大家. 在你找来棍棒准备揍我之前,请允许我先解释一下. 在过去的6年时间里,我越来越坚定地有了这样一个想法,那就是:成为一名杰出的程序员其实跟写代码没有太大的关系.做程序员确实需要一些技能,当然,还要有坚韧不拔的精神.但除此之外,更重要的还是要有良好的沟通技巧. 杰出的程序员跟勉强过得去的程序员之间的差别,不在于他们掌握了多少种编程语言,也不在于他们谁更擅

《高效能程序员的修炼》一大道至简

大道至简 高效能程序员的修炼 作者在Twitter上发的一条短讯: "你永远都有简化的空间." 11:29 AM – 2012-5-21 Rich Skrenta在"Code is our enemy"(代码是我们的敌人)一文中是这么说的: 代码不是什么好东西.代码会随着时间的推移慢慢腐烂.代码需要周期性的维护.代码里还藏有bug.新增功能意味着旧的代码需要被修改.你的代码越多,bug能藏身的地方就越多,迁出(checkout)或者编译的时间也就越长,新员工理解你的

《高效能程序员的修炼》一一路向前冲

一路向前冲 高效能程序员的修炼就运营Stack Overflow这个公司而言,我采用的商业策略全来自一个人,而且只有这一个人:Curtis Armstrong. 更准确地说,是Curtis Armstrong在1985年的经典荒诞青春喜剧<再见人生>(<Better Off Dead>)中所扮演的Charles De Mar.当他被问到如何从一个特别险峻的高山上滑雪下去的时候,他回答道: 沿着那条路下去,一定要快.如果有什么东西挡住了你的去路--绕开它! 在我们宣布Stack Ov

《高效能程序员的修炼》一磨刀不误砍柴工

磨刀不误砍柴工 高效能程序员的修炼作为一名软件开发人员,你该如何磨快你的锯子? "磨锯子"实际上是一个代名词,泛指一切编程以外的活动(不必编写代码),而这些活动(从理论上来说)能使你成为一名更出色的程序员.这个词源自于Covey的一本书:<高效能人士的7个习惯>(<The 7 Habits of Highly Effective People>).1 有个人在山间漫步,偶遇一位伐木工.他便停下来观察这位伐木工,看他热火朝天地锯一棵很大的树.他发现这位伐木工干得大

《高效能程序员的修炼》一性能致胜

性能致胜 高效能程序员的修炼在Stack Overflow和Stack Exchange上,我们总是非常强调性能.不仅仅因为我们是性能的发烧友(我很内疚),也因为我们认为速度是一个竞争优势.已经有大量的实验数据表明,网站载入和显示的速度越慢,使用它的人就会越少. Google发现,显示10个结果的网页需要0.4秒来生成,显示30个结果的网页需要0.9秒来生成.半秒钟的延迟会造成20%的流量下降.半秒钟的延迟就扼杀了用户的满意度. 在A/B1测试中,亚马逊试着以100毫秒为单位逐步增加页面的延迟,