阅读优秀代码是提高开发人员修为的一种捷径

 

　编者按：原文作者Alan Skorkin是一名软件开发人员，他在博客中分享对软件开发相关的心得，其中有很

多优秀的文章，本文是其中的另一篇。Alan认为：阅读优秀代码是提高开发人员修为的一种捷径。以下是全

文。

　　我突然想起来，很多程序员都讨厌阅读代码。来吧，承认吧！ 每个人都喜欢编写代码，编代码是件趣事。

另一方面，阅读代码也不容易。 不仅不容易（编注：参见《微软资深软件工程师：阅读代码不容易》）， 而且

还非常枯燥，咱们要面对这一事实。任何不是你的代码都不怎样。（虽然我们没有说出来，但我们都是这样想

的。） 即便是你自己几个小时之前写的代码，也会看起来很烂。时间越久，看起来越烂。 所以，为什么你要浪

费时间去看其他人的糟糕代码，而你完全可以利用这段时间编写你自己的优秀代码。 其实我们可以一试，几个

小时之后回头再看，看看你的代码是否还依旧优秀。 如果你不能吸收前辈大师的经验知识，那你永远都无法成

为一位大师。 成为大师的方法之一是，找到一位大师，让其倾囊传授其所知。 有这种可能么？当然了，有这可

能，虽然机会不大，但你必须极其走运。 不过你不必十分走运，因为我们幸运地处于这样一个职业，一个充满

着大师知识和技能的职业，等待我们去汲取吸收，这些东西就在他们所编写的代码中。 你要做的就是去阅读代

码，当然了，这或许耗时不少，毕竟没有人坐在那里给你讲解，但这种方法的成效还很高。 打个比方，要想成

为一名卓越的木匠，得观察大量结构优良的家具。

　　我喜爱阅读代码，我的直觉告诉我，你也会从中获益颇丰。虽然阅读过程恼人并烦人，但其回报是非常值

得你为之努力的。 说到这个，如果你想成为一名卓越的作家，你会专注于写作么？ 你或许已经尝试，但你并没

有走得很远。 大多数的伟大作家也是如饥似渴的读者，这是一个普遍事实。 在你能写出任何拿得出手的东西之

前，你需要品读其他伟大作家，吸收不同的风格，看看前辈已尝试过的东西，从中吸取精华。 你的知识会慢慢

增长，你自己的作品最终会透露出些许成熟，你也会找到一种“感觉”。 编写代码和写作没什么不同，如果你

都没有阅读过任何卓越的代码，你为什么期望自己能写出像样的代码呢？ 你显然不应该那样。对于程序员来

说，阅读卓越代码就如同作家阅读优秀书籍一样重要（这话可不是我说的，这是Peter Norvig（Google研究院

总监）说的，他非常优秀，大家也要向他学习了）。

　　即便所有这些都无法让你信服，那这里有一个不可置否的事实。 对你作为一名专业开发人员的生存来说，

善于阅读代码至关重要。 如今，任何有一定规模的项目，都是团队的成果。所以，你通常要处理、修改和扩展

大量不是你写的代码。 因此，阅读代码可能是你能掌握的最常用并最有用的技能。挺过这个难关，好好掌握。

　　如何阅读代码？像某些人一样……

　　我已经记不清有多少次看到程序员（用鼠标）滚上滚下地看着不熟悉的代码，几分钟过后，他们的脸上浮

现出不悦的表情。 他们不久后会宣告说，那代码不值一读，为什么要浪费时间呢？我们只能用其他方法解决问

题。 我不确定（他们）在期待什么，是通过潜移默化来吸收代码的含义，还是集中精神盯着代码来得到启发？

你不能只靠长时间盯着代码来阅读代码，你要理解它并化为己用。 这里有一些我喜欢用的技巧，虽然这不是一

份详尽的列表，但我发现其中有些特别有用。

• 1.尽力构建并运行代码。这通常是一个简单的步骤，就像你在看可运行的代码（这和随机代码相反）。

不过，并非总是如此。通过构建和执行代码，你能从中学到很多上层代码结构。 说到工作代码，你是否

非常熟悉如何构建你的当前项目？ 虽然构建通常非常复杂，但通过构建并生成可执行的代码，你能学到

很多。

• 2. 不要只注重细节。你要做的第一件事是，在你正阅读的代码中，找到代码结构和风格的。 首先浏览

一下代码，尽力理解不同代码段要做什么。这会让你熟整个代码的上层结构，你也能领会到你正处理的

代码的一些构思（良好架构和意大利面条等）。 这时候，你可以找到切入点（不管它是什么，主函数、

servlet或控制器等），并查看代码如何在那里分支。 不要在这上面花过多的时间，随着你愈加熟悉代

码，你可以随时回来查看。

• 3. 确信自己理解所有结构。除非你碰巧是所用编程语言的首席专家，否则该语言有些它能做的事你可

能还不知道。当你在浏览代码时，记下所有你或许不熟悉的结构。 如果有很多不熟悉的结构，你要做的

下一步非常明显。 如果你不知道代码要做什么，那你就走不了很远。 即便只有几个你不熟悉的结构，

你应当深入查看。 你现在是在探索你所用编程语言中你以前不知道的东西，为此花几个小时来阅读代

码，我也非常乐意。

• 4. 既然你对大多数结构已有很好了解，那现在是该做些随机深入研究了。就像步骤2，开始浏览代码，

当这次 要挑选一些随机函数或类，并开始逐行详细查看。 这是硬仗开始的地方，但也是你要取得主要

成功的地方。 这里的构想，会形成你正在查看的代码库的思维模式。 也不要在这上面花过长的时间，

但在继续前行之前，你要尽力并极大吸收一些有内容的代码块。 这个步骤，你也可以随时反复回过头

来，每次你都会了解更多的背景，并收获更多。

• 5. 毫无疑问，在前面这些步骤中，肯定有你困惑的地方，所以这是你做些测试的最佳时间。在测试的

时候，你的麻烦可能会更少，同时你也能理解代码。 我一直感到奇怪，开发人员忽略一套写得很好很全

面的测试代码，而尽力去阅读并理解某些代码。 当然了，有时候并没有测试。

• 6. 如果你说没有测试，那这听起来是编写测试的时候了。（编写测试）有很多益处，有助于你自己的

理解，有助于你提升代码库，阅读代码时也能编写代码，这是该你出手做些事的时候。 即便已经有了测

试，通常你也可以编写一些测试，你总能受益的。 测试代码通常需要换种方式思考问题，那些你以前不

太明了的概念也会变得更清晰。

• 7. 提取奇特的代码，使其成为单独的程序。我发现阅读代码是个非常有趣的练习，即便只为节奏变化。

即便你不了解代码的底层细节，你或许能知道一些代码在上层结构上要做什么。 什么不提取一些特定的

函数，单独列为独立的程序。 当你在执行小段程序时，调试也会更简单。反过来说，可能还需要一些额

外的步骤，才能理解你正查看的代码。

• 8. 代码不干净？有异味？ 为什么不重构它？ 我并不建议你重写整个代码库，但重构部分代码，真的有

助于你理解层次上升一层。 把你理解的函数拿出来，改成独立的函数。 在你知道之前，原来的大函数

看起来易管理，你可以在脑海中修改它。 重构允许你把代码变成自己的，无需完成重写代码。 如果有

好的测试，有助于重构，但即便你没有好的测试，抽取你确定的函数并做测试。 即便测试看起来完全不

充分，但作为一个开发人员，你得学着相信你的技能，有时候你只需努力去做（重构）。（如果你必须

重构，你通常都可以把代码恢复原 状。）

• 9. 如果没什么能帮上忙，那你就找个阅读代码的同伴。或许并非只有你一个人能从这代码中获益，所以

去找一个 人，一起阅读代码吧。 但你别找专家，他们会从上层结构上，向你解释所有东西，你会错失

那些你自己详细查看代码时所能学到的细微差别。 然而，如果不见效的话，你也不能理解，有时候，你

能做的最好的事就是去问。 向你的同事请教，如果你正在阅读开源代码，可以在互联网上找人问问。

但是你要记住，这是最后一步，而不是第一步。

　　如果我时间紧迫，需要快速合理地理解某些代码，并且我只能挑选上述步骤的其中一个，那我会选择“重

构”（即：第8个步骤）。 虽然你能理解的东西不会很多，但那些你领会的东西，你会牢牢记住的。 总之，有

件事你需要记在心里。 如果你新接触一个重要的代码库，你不可能立即能理解它。 这需要数天、数周和数月的

潜心努力，接受这个事实。 即便有一位专家和你在一起，也不能明显地缩短时间（。 然而，当涉及到代码库

时，如果你能耐心并有条不紊地阅读（和编写）代码，你最终能熟悉项目的方方面面，你能成为大牛。 你或者

是逃避阅读代码，经常寻求某人帮你讲解某事。 我知道我会成为哪一种人。

　　寻找阅读代码的机遇 – 不要错失

　　我们喜欢编写新代码，是因为我们这次能正确处理问题。 好吧，也许不是这次，但一定是下次。 事实上

是，你经常改进你的技术，但你从没有恰当地处理问题。 这就是编写新代码的价值所在，你可以历练并磨练你

的技能，但阅读和把玩其他人编写的代码，（如果没有更多的价值，）也是有同样多的价值。 你不仅能从中获

得一些有价值的技术知识，也能收获领域知识，领域知识通常仍具更多价值（毕竟，代码是文档的最终形

式）。

　　即便代码写得很神秘，无任何惯例可言，但还是有价值。 你知道我在说的代码，它几乎看起来晦涩难懂，

但不是有意而为之（因某些原因，Perl语言代码通常是这样的）。 不管什么时候我看到那样的代码，我都会这

样想： 把它想象成只有你破译它后才能学到的东西。 是的，这是主要的痛楚之处，但要接受它，有时候你自己

也会因琐碎的原因而写出那种使人困惑的代码（否认没有用，你知道这是真的）。 好了，如果你花些时间来阅

读那样的代码，你更有可能最终写出同样的代码。并不说你将会写出那样的代码，但你有能力写出那样的代

码。 最后，态度通常是最重要的（编注：态度决定一切）。 如果你视阅读代码为日常繁琐的工作，那它就是

（繁琐的工作），并且你会逃避，但如果你视其为一个机遇，那好事终将到来。