转载

增进编程技能的万全之计

编者按：本文最初是在2010年5月为Fuel Your Coding撰写的，然而该网站现已关闭，为了能让更多人读到，我重新发布了本文。我曾想过针对技术的最新发展对本文进行更新，但原有内容其实已经很棒了。有些内容由于过时显得有些好笑，不过总的来说还行。请慢用！

增进编程能力最明显的方式就是尽可能编写更多代码，这一点大家都清楚。然而我保证还可以通过另一种与写代码完全“背道而驰”的方式增进你的编程能力。下文将尽可能清楚地介绍这种方法：

如果希望大幅增进自己的编程技能，你还需要阅读别人写的代码。

信不信在你。其实你应该相信。如果愿意一试，我相信你会觉得这么做所付出的宝贵时间是非常值得的。

本文将帮你选择可供阅读的代码，并介绍最佳阅读“姿势”。如果已经习惯于阅读别人的代码，你可能已经总结出其他更适合自己的方法。但如果还没这么做过，那就抓紧时间开始阅读吧。

读什么

这个问题很重要，也很难给出具体建议。我并不会按照自己的想法直接给出建议你去阅读的代码，因为这完全取决于你的具体情况。我会提供一些指导，帮你选择适合自己阅读的内容。

阅读你所依赖的代码

首先可以读一读你目前正在使用的任何插件或库的代码，例如：

某个你非常喜欢的WordPress插件的代码
某个你觉得很有用的Ruby gem的代码
某个你经常用到的jQuery插件的代码

这些东西都很适合阅读。你已经非常熟悉它们的公开API，因此理解其内部工作原理的障碍会显得小很多。此外作为这些代码的用户，你还可以借机为其贡献文档，实现新的功能，或通过其他某种方式回报相关的项目。

阅读让你印象深刻的代码

还记得当我第一次看到 280 Slides 后产生的想法：“这真是让人印象深刻。”很快我发现驱动这个网站的代码来自一个开源的Cappuccino项目。我将这一发现深藏在脑海中，最后当我开始参与使用 Cappuccino 构建的另一个让人印象深刻的应用时，我知道这个项目可以从中获益匪浅。最近有什么东西让你印象深刻吗？是否是开源的？如果是，那么也许很值得一读，因为代码本身可能会像应用程序一样让你留下深刻的印象。

阅读你所敬重的人写的代码

增进编程技能的万全之计

如果从事开源软件的开发有一段时间了，你也许已经有了几个自己敬重的程序员。我脑海中就时常浮现着几个程序员，他们写的代码堪称惊艳。

就算暂时想不到这样的人，其实这样的人也很好找。例如上文提到的两类代码（你所依赖的代码，让你印象深刻的代码）的作者就是不错的候选人。

阅读你可以完全领会的代码

如果是那种有冒险精神的人，你可能会考虑读读诸如Ruby on Rails、Drupal，或jQuery等大型项目的代码。我个人建议一开始尽量别选择这种项目，除非你本身已经是非常有经验的代码阅读者。

大型项目往往包含很多组件，最终你可能会过度地纠结于从各种现成的成果中学到知识这一概念本身。困惑往往会导致挫折，大型项目通常更容易让人困惑，进而让你的阅读积极性受挫。选择一个小型项目来阅读，这种做法的优势在于你可以在自己的脑海中全盘掌握整个项目的逻辑，进而只需要发现各种细节并从中学习就行了。

如何读

选好要阅读的代码后，最佳阅读方式是什么？我平时阅读过很多代码，可以提供几个能帮你获得最大化收益的方法。

从大局着眼

增进编程技能的万全之计

假设你至少已经能在宏观层面了解自己要阅读的代码所实现的功能。如果还不了解，建议阅读项目的网站、教程、文档，以及除了代码本身之外，其他任何能让你对整个项目获得更深入了解的东西。

厘清这件事之后，建议首先全局了解整个项目的结构。取决于所选项目代码基的规模，具体的工作量可能各异，但任何超过一个文件的项目可能都需要花费略多一些的时间。

首先需要注意文件结构，为此可以选择可以体现文件夹层次结构的编辑器，如TextMate。例如Twitter Ruby gem的结构是这样的。

这一步的目标在于熟悉源代码本身。确定哪些文件包含/需要/加载了其他文件，大部分代码在哪个文件中，是否使用了任何名称空间，以及其他一些本质特征。获得了宏观的了解后，可以开始深入细节了。

记录你的发现和结论

代码的阅读不应该是一种被动行为。建议你能在阅读的同时添加自己的备注，随着对程序流程的理解逐渐深入，记录你的猜测和结论。一开始你的备注可能是类似这样的：

# 我觉得这个函数需要在'initialize'之后调用
# 这个公式是做什么用的？
# 可以确定在17行之后这个函数失去范围了

随着理解的深入，也许可以陆续删除一开始留下的浅显的备注，并开始写一些更有意义、更权威，甚至能对整个项目产生真正回报的备注。

一定要测试

希望你所选择的项目提供了测试套件。如果没有，那么本节内容可以全部跳过（或者找个提供测试套件的项目）。

阅读其他人写的代码时，测试是一种很好的起点，因为其中记录了不同代码本应实现的功能。一些测试可能包含更翔实的信息，但无论测试写得多好通常你都会发现，从测试中了解到的程序员的意图往往要比你自己从具体实现中的判断简单很多。在阅读的同时，可以试着让测试套件成功运行，这样可以确保你的开发环境已正确配置，进而让自己进行各种改动的时候更自信。

执行，修改，执行

谁说读代码就只是“读”代码？如果能将一切拆解又重新组装起来，才能获得真正的理解。还记得做过的各种测试吗？让测试失败几次，增加一些内容，或在不产生破坏作用的情况下试着更改具体实现。试着增添一些你觉得酷的小功能，或者配置项目级的日志并将不同阶段的代码打印输出。这也算“读”？当然！不过此时更像是自己身临其境的历险，而不仅仅是阅读别人写好的推理小说。这是一种很棒的做法！