编者按:原文作者Alan Skorkin是一名软件开发人员,他在博客中分享对软件开发相关的心得,其中有很多优秀的文章,本文是其中的另一篇。Alan认为:阅读优秀代码是提高开发人员修为的一种捷径。以下是全文。
我突然想起来,很多程序员都讨厌阅读代码。来吧,承认吧! 每个人都喜欢编写代码,编代码是件趣事。 另一方面,阅读代码也不容易。 不仅不容易(编注:参见《微软资深软件工程师:阅读代码不容易》),而且还非常枯燥,咱们要面对这一事实。任何不是你的代码都不怎样。(虽然我们没有说出来,但我们都是这样想的。)即便是你自己几个小时之前写的代码,也会看起来很烂。时间越久,看起来越烂。所以,为什么你要浪费时间去看其他人的糟糕代码,而你完全可以利用这段时间编写你自己的优秀代码。其实我们可以一试,几个小时之后回头再看,看看你的代码是否还依旧优秀。 如果你不能吸收前辈大师的经验知识,那你永远都无法成为一位大师。成为大师的方法之一是,找到一位大师,让其倾囊传授其所知。 有这种可能么?当然了,有这可能,虽然机会不大,但你必须极其走运。不过你不必十分走运,因为我们幸运地处于这样一个职业,一个充满着大师知识和技能的职业,等待我们去汲取吸收,这些东西就在他们所编写的代码中。你要做的就是去阅读代码,当然了,这或许耗时不少,毕竟没有人坐在那里给你讲解,但这种方法的成效还很高。打个比方,要想成为一名卓越的木匠,得观察大量结构优良的家具。
我喜爱阅读代码,我的直觉告诉我,你也会从中获益颇丰。虽然阅读过程恼人并烦人,但其回报是非常值得你为之努力的。说到这个,如果你想成为一名卓越的作家,你会专注于写作么? 你或许已经尝试,但你并没有走得很远。大多数的伟大作家也是如饥似渴的读者,这是一个普遍事实。在你能写出任何拿得出手的东西之前,你需要品读其他伟大作家,吸收不同的风格,看看前辈已尝试过的东西,从中吸取精华。你的知识会慢慢增长,你自己的作品最终会透露出些许成熟,你也会找到一种“感觉”。编写代码和写作没什么不同,如果你都没有阅读过任何卓越的代码,你为什么期望自己能写出像样的代码呢?你显然不应该那样。对于程序员来说,阅读卓越代码就如同作家阅读优秀书籍一样重要(这话可不是我说的,这是Peter Norvig(Google研究院总监)说的,他非常优秀,大家也要向他学习了)。
即便所有这些都无法让你信服,那这里有一个不可置否的事实。 对你作为一名专业开发人员的生存来说,善于阅读代码至关重要。如今,任何有一定规模的项目,都是团队的成果。所以,你通常要处理、修改和扩展大量不是你写的代码。因此,阅读代码可能是你能掌握的最常用并最有用的技能。挺过这个难关,好好掌握。
如何阅读代码?像某些人一样……
我已经记不清有多少次看到程序员(用鼠标)滚上滚下地看着不熟悉的代码,几分钟过后,他们的脸上浮现出不悦的表情。他们不久后会宣告说,那代码不值一读,为什么要浪费时间呢?我们只能用其他方法解决问题。我不确定(他们)在期待什么,是通过潜移默化来吸收代码的含义,还是集中精神盯着代码来得到启发?你不能只靠长时间盯着代码来阅读代码,你要理解它并化为己用。 这里有一些我喜欢用的技巧,虽然这不是一份详尽的列表,但我发现其中有些特别有用。
•1.尽力构建并运行代码。 这通常是一个简单的步骤,就像你在看可运行的代码(这和随机代码相反)。不过,并非总是如此。通过构建和执行代码,你能从中学到很多上层代码结构。 说到工作代码,你是否非常熟悉如何构建你的当前项目?虽然构建通常非常复杂,但通过构建并生成可执行的代码,你能学到很多。
•2. 不要只注重细节。 你要做的第一件事是,在你正阅读的代码中,找到代码结构和风格的。首先浏览一下代码,尽力理解不同代码段要做什么。这会让你熟整个代码的上层结构,你也能领会到你正处理的代码的一些构思(良好架构和意大利面条等)。这时候,你可以找到切入点(不管它是什么,主函数、servlet或控制器等),并查看代码如何在那里分支。不要在这上面花过多的时间,随着你愈加熟悉代码,你可以随时回来查看。
3. 确信自己理解所有结构。 除非你碰巧是所用编程语言的首席专家,否则该语言有些它能做的事你可能还不知道。当你在浏览代码时,记下所有你或许不熟悉的结构。如果有很多不熟悉的结构,你要做的下一步非常明显。 如果你不知道代码要做什么,那你就走不了很远。 即便只有几个你不熟悉的结构,你应当深入查看。你现在是在探索你所用编程语言中你以前不知道的东西,为此花几个小时来阅读代码,我也非常乐意。
•4. 既然你对大多数结构已有很好了解,那现在是该做些随机深入研究了。 就像步骤2,开始浏览代码,当这次要挑选一些随机函数或类,并开始逐行详细查看。 这是硬仗开始的地方,但也是你要取得主要成功的地方。这里的构想,会形成你正在查看的代码库的思维模式。 也不要在这上面花过长的时间,但在继续前行之前,你要尽力并极大吸收一些有内容的代码块。这个步骤,你也可以随时反复回过头来,每次你都会了解更多的背景,并收获更多。
•5. 毫无疑问,在前面这些步骤中,肯定有你困惑的地方,所以这是你做些测试的最佳时间。 在测试的时候,你的麻烦可能会更少,同时你也能理解代码。 我一直感到奇怪,开发人员忽略一套写得很好很全面的测试代码,而尽力去阅读并理解某些代码。 当然了,有时候并没有测试。
•6. 如果你说没有测试,那这听起来是编写测试的时候了。 (编写测试)有很多益处,有助于你自己的理解,有助于你提升代码库,阅读代码时也能编写代码,这是该你出手做些事的时候。 即便已经有了测试,通常你也可以编写一些测试,你总能受益的。 测试代码通常需要换种方式思考问题,那些你以前不太明了的概念也会变得更清晰。
•7. 提取奇特的代码,使其成为单独的程序。我发现阅读代码是个非常有趣的练习,即便只为节奏变化。即便你不了解代码的底层细节,你或许能知道一些代码在上层结构上要做什么。 什么不提取一些特定的函数,单独列为独立的程序。当你在执行小段程序时,调试也会更简单。反过来说,可能还需要一些额外的步骤,才能理解你正查看的代码。
•8. 代码不干净?有异味? 为什么不重构它?我并不建议你重写整个代码库,但重构部分代码,真的有助于你理解层次上升一层。 把你理解的函数拿出来,改成独立的函数。在你知道之前,原来的大函数看起来易管理,你可以在脑海中修改它。 重构允许你把代码变成自己的,无需完成重写代码。如果有好的测试,有助于重构,但即便你没有好的测试,抽取你确定的函数并做测试。即便测试看起来完全不充分,但作为一个开发人员,你得学着相信你的技能,有时候你只需努力去做(重构)。(如果你必须重构,你通常都可以把代码恢复原状。)
•9. 如果没什么能帮上忙,那你就找个阅读代码的同伴。或许并非只有你一个人能从这代码中获益,所以去找一个人,一起阅读代码吧。 但你别找专家,他们会从上层结构上,向你解释所有东西,你会错失那些你自己详细查看代码时所能学到的细微差别。然而,如果不见效的话,你也不能理解,有时候,你能做的最好的事就是去问。 向你的同事请教,如果你正在阅读开源代码,可以在互联网上找人问问。但是你要记住,这是最后一步,而不是第一步。
如果我时间紧迫,需要快速合理地理解某些代码,并且我只能挑选上述步骤的其中一个,那我会选择“重构”(即:第8个步骤)。虽然你能理解的东西不会很多,但那些你领会的东西,你会牢牢记住的。 总之,有件事你需要记在心里。如果你新接触一个重要的代码库,你不可能立即能理解它。 这需要数天、数周和数月的潜心努力,接受这个事实。即便有一位专家和你在一起,也不能明显地缩短时间(。然而,当涉及到代码库时,如果你能耐心并有条不紊地阅读(和编写)代码,你最终能熟悉项目的方方面面,你能成为大牛。你或者是逃避阅读代码,经常寻求某人帮你讲解某事。 我知道我会成为哪一种人。
寻找阅读代码的机遇 – 不要错失
我们喜欢编写新代码,是因为我们这次能正确处理问题。 好吧,也许不是这次,但一定是下次。事实上是,你经常改进你的技术,但你从没有恰当地处理问题。这就是编写新代码的价值所在,你可以历练并磨练你的技能,但阅读和把玩其他人编写的代码,(如果没有更多的价值,)也是有同样多的价值。你不仅能从中获得一些有价值的技术知识,也能收获领域知识,领域知识通常仍具更多价值(毕竟,代码是文档的最终形式)。
即便代码写得很神秘,无任何惯例可言,但还是有价值。你知道我在说的代码,它几乎看起来晦涩难懂,但不是有意而为之(因某些原因,Perl语言代码通常是这样的)。不管什么时候我看到那样的代码,我都会这样想: 把它想象成只有你破译它后才能学到的东西。是的,这是主要的痛楚之处,但要接受它,有时候你自己也会因琐碎的原因而写出那种使人困惑的代码(否认没有用,你知道这是真的)。好了,如果你花些时间来阅读那样的代码,你更有可能最终写出同样的代码。并不说你将会写出那样的代码,但你有能力写出那样的代码。最后,态度通常是最重要的(编注:态度决定一切)。如果你视阅读代码为日常繁琐的工作,那它就是(繁琐的工作),并且你会逃避,但如果你视其为一个机遇,那好事终将到来。
编者后话
你会经常去阅读优秀的开源代码么?欢迎在评论中和大家分享。
译文出处:伯乐在线 - 职场博客
译文链接:http://www.jobbole.com/entry.php/471
原文作者:Alan Skorkin编译:伯乐在线 敏捷翻译组 - 关关