微软资深软件工程师：阅读代码真的很难

编者按：原文做者EricLippert是一名资深软件设计工程师，从1996年起一直在微软开发部门任职，协助设计并实现VBScript、 JScript、JScript.NET、Windows Script Host、Visual Studio Tools for Office 和 C#。

Escalation的工程师JeremyK在他的博客中问到：

你是怎么教人们快速深刻挖掘不熟悉的代码（不是本身所写的）？我学习如何编程的方法很传统 —— 本身动手编码。但我如今很纠结：究竟是集中精神阅读源码，仍是本身编写。对我而言，彷佛惟一有效的方法就是本身写过。

不是和Jeremy开玩笑，写代码的确没有读代码难。

首先，我赞成你的见解，几乎不多有人能读代码但不会写代码。这不像天然书面语或口语，理解他人的意思并不须要去理解他们为何要那样说。好比，若是我说：

“写代码有两种方式：一种严格且详细，另外一种模糊且草率。前者生成简洁分层的婚礼蛋糕，后者倒是意大利面条。”

上面这句话产生一个平衡且幽默的效果，但即便听众和读者不理解我使用“零照应”和“并列句”这样的文字技巧，也会理解我要说的意思。可是说到代码，既要从代码自己中理解代码做者的意图，又要理解代码产生的预计效果，这二者都极为重要。

所以，我又回到那个问题了，有些人须要快速切入代码，但不须要动手写代码，那咱们如何编写适合这些人的代码？

下面是我在编写代码时，尽力去作的事，目的就是使其余人能轻松阅读：

• 使代码听从工具。Object Browsers和Intellisense虽然很好，但我告诉你，我是守旧派。若是找不到我想要的，我会不高兴。什么使得代码成为可查询的呢?
  • 像"i"这样的变量名很差。若是没有明确的错误提示，你就没法轻易查找代码。
  • 避免使用是其余名字前缀的名字。好比，在代码中有个“perfExecuteManifest”，若是再有一个“perfExecuteManifestInitialize”，这就会让我抓狂，由于每次在源码中查询前者时，我不得不费力地过滤掉后者全部的实例。
  • “临时传递数据”（tramp data）应使用相同的名字。所谓“临时传递数据”（tramp data），就是指那些传递给方法A的变量，还要传给方法B的变量。这两类变量其实是相同的，因此若是它们有着相同的名字，则更好。
  • 别用宏来重命名东西。若是有个方法叫get_MousePosition，那别这样GETTER(MousePosition)来声明该方法。由于我会找不到实际的方法名。
  • Shadowing会引发不少问题，请不要用它。

• 坚持使用一种命名模式。若是你打算用匈牙利命名法，那就坚持并普遍使用，不然将拔苗助长。使用匈牙利命名法来记录数据，而不是存储类型；记录广泛事实，而不是临时条件。

• 使用断言来记录先决条件（preconditions）和后置条件（postconditions）。

• 别缩写英文单词。确切来讲，别缩写成稀奇古怪的形式。在脚本引擎中，有个变量名叫“NME”，这让我很是抓狂！它应当叫“VariableName”。

• C语言标准运行时库的设计不是很优秀。别去效仿它。

• 别写“聪明”的代码；当代码出现问题，维护代码的程序员没时间去理解你的聪慧。

• 理解编程语言特性的设计初衷，使用这些特性去作它们适合完成的工做，而不是它们能作到的工做。例如：别把异常当作通常的流控制机制来使用（即使你能作到），而应该用它们来报告错误。别强制把接口指针转换成类指针，即使你知道这样没问题。

• 按功能单元划分源码树，而不是按组织结构。好比：我目前所在团队中，有2个根子目录的名字是“Frameworks”和 “Integration”，这是两个团队的名字。不巧的是，Frameworks团队名下有一个叫“Adaptor”的子目录，而“Adaptor”倒是Integration的子目录，这就很是使人迷惑。同理，（若是）有着相同子目录的不一样的子树，有些是客户端的组件，有些是服务端的组件；有些是管理组件，有些是非管理组件；有些是处理型组件，有些是非处理型组件；有些是零售组件，有些内部测试工具。这就会乱七八糟的。

固然，我实际上根本没有回答Jeremy的问题——如何调试不是我写的代码？

这取决于个人目的。若是我只是由于一个bug，而深挖一段具体的代码，我会在调试器中逐步跟踪全部代码，写下我“走过”的调用分支，记录下哪些方法是特定数据结构的“生产者”，哪些方法是“消费者”；我也会仔细盯着输出窗口，查看出现的有用信息；还要打开异常捕捉器，由于异常一般是问题所在。设置断点；我会记录全部和我上面建议相反的地方，由于这些东西极可能误导了我。

若是我想在理解一段代码后修改它，我一般是从代码头部开始，或者先查找公共方法。我要知道类是如何实现的，它是如何扩展的，它的做用，它是如何嵌入整个代码中的？我会尽力理解这些东西后，才去了解这些特定部分（代码）是如何实现的。这耗时虽更长些，但若是你准备改动复杂代码，你应当那样作。

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

我已经记不清有多少次看到程序员（用鼠标）滚上滚下地看着不熟悉的代码，几分钟事后，他们的脸上浮现出不悦的表情。他们不久后会宣告说，那代码不值一读，为何要浪费时间呢？咱们只能用其余方法解决问题。我不肯定（他们）在期待什么，是经过潜移默化来吸取代码的含义，仍是集中精神盯着代码来获得启发？你不能只靠长时间盯着代码来阅读代码，你要理解它并化为己用。 这里有一些我喜欢用的技巧，虽然这不是一份详尽的列表，但我发现其中有些特别有用。

• 1. 尽力构建并运行代码。这一般是一个简单的步骤，就像你在看可运行的代码（这和随机代码相反）。不过，并不是老是如此。经过构建和执行代码，你能从中学到不少上层代码结构。说到工做代码，你是否很是熟悉如何构建你的当前项目？虽然构建一般很是复杂，但经过构建并生成可执行的代码，你能学到不少。

• 2. 不要只注重细节。你要作的第一件事是，在你正阅读的代码中，找到代码结构和风格。首先浏览一下代码，尽力理解不一样代码段要作什么。这会让你熟整个代码的上层结构，你也能领会到你正处理的代码的一些构思（良好架构和意大利面条等）。这时候，你能够找到切入点（无论它是什么，主函数、servlet 或控制器等），并查看代码如何在那里分支。不要在这上面花过多的时间，随着你越发熟悉代码，你能够随时回来查看。

• 3. 确信本身理解全部结构。除非你碰巧是所用编程语言的首席专家，不然该语言有些它能作的事你可能还不知道。当你在浏览代码时，记下全部你或许不熟悉的结构。若是有不少不熟悉的结构，你要作的下一步很是明显。若是你不知道代码要作什么，那你就走不了很远。 即使只有几个你不熟悉的结构，你应当深刻查看。你如今是在探索你所用编程语言中你之前不知道的东西，为此花几个小时来阅读代码，我也很是乐意。

• 4. 既然你对大多数结构已有很好了解，那如今是该作些随机深刻研究了。 就像步骤2，开始浏览代码，当此次要挑选一些随机函数或类，并开始逐行详细查看。这是硬仗开始的地方，但也是你要取得主要成功的地方。这里的构想，会造成你正在查看的代码库的思惟模式。也不要在这上面花过长的时间，但在继续前行以前，你要尽力并极大吸取一些有内容的代码块。这个步骤，你也能够随时反复回过头来，每次你都会了解更多的背景，并收获更多。

• 5. 毫无疑问，在前面这些步骤中，确定有你困惑的地方，因此这是你作些测试的最佳时间。在测试的时候，你的麻烦可能会更少，同时你也能理解代码。 我一直感到奇怪，开发人员忽略一套写得很好很全面的测试代码，而尽力去阅读并理解某些代码。固然了，有时候并无测试。

• 6. 若是你说没有测试，那这听起来是编写测试的时候了。 （编写测试）有不少益处，有助于你本身的理解，有助于你提高代码库，阅读代码时也能编写代码，这是该你出手作些事的时候。 即使已经有了测试，一般你也能够编写一些测试，你总能受益的。 测试代码一般须要换种方式思考问题，那些你之前不太明了的概念也会变得更清晰。

• 7. 提取奇特的代码，使其成为单独的程序。我发现阅读代码是个很是有趣的练习，即使只为节奏变化。即使你不了解代码的底层细节，你或许能知道一些代码在上层结构上要作什么。为何不提取一些特定的函数，单独列为独立的程序。当你在执行小段程序时，调试也会更简单。反过来讲，可能还须要一些额外的步骤，才能理解你正查看的代码。

• 8. 代码不干净？有异味？ 为何不重构它？我并不建议你重写整个代码库，但重构部分代码，真的有助于你的理解层次上升一层。 把你理解的函数拿出来，改为独立的函数。在你知道以前，原来的大函数看起来易管理，你能够在脑海中修改它。 重构容许你把代码变成本身的，无需完成重写代码。若是有好的测试，有助于重构，但即使你没有好的测试，抽取你肯定的函数并作测试。即使测试看起来彻底不充分，但做为一个开发人员，你得学着相信你的技能，有时候你只需努力去作（重构）。（若是你必须重构，你一般均可以把代码恢复原状。）

• 9. 若是没什么能帮上忙，那你就找个阅读代码的同伴。或许并不是只有你一我的能从这代码中获益，因此去找一我的，一块儿阅读代码吧。 但你别找专家，他们会从上层结构上，向你解释全部东西，你会错失那些你本身详细查看代码时所能学到的细微差异。然而，若是不见效的话，你也不能理解，有时候，你能作的最好的事就是去问。向你的同事请教，若是你正在阅读开源代码，能够在互联网上找人问问。可是你要记住，这是最后一步，而不是第一步。

若是我时间紧迫，须要快速合理地理解某些代码，而且我只能挑选上述步骤的其中一个，那我会选择“重构”（即：第 8 个步骤）。虽然你能理解的东西不会不少，但那些你领会的东西，你会紧紧记住的。总之，有件事你须要记在内心。若是你新接触一个重要的代码库，你不可能当即能理解它。这须要数天、数周和数月的潜心努力，接受这个事实。即使有一位专家和你在一块儿，也不能明显地缩短期。然而，当涉及到代码库时，若是你能耐心并有条不紊地阅读（和编写）代码，你最终能熟悉项目的方方面面，你能成为大牛。你或者是逃避阅读代码，常常寻求某人帮你讲解某事。我知道我会成为哪种人。

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

咱们喜欢编写新代码，是由于咱们此次能正确处理问题。好吧，也许不是此次，但必定是下次。事实上是，你常常改进你的技术，但你从没有恰当地处理问题。这就是编写新代码的价值所在，你能够历练并磨练你的技能，但阅读和把玩其余人编写的代码，（若是没有更多的价值，）也是有一样多的价值。你不只能从中得到一些有价值的技术知识，也能收获领域知识，领域知识一般仍具更多价值（毕竟，代码是文档的最终形式）。

即使代码写得很神秘，无任何惯例可言，但仍是有价值。你知道我在说的代码，它几乎看起来晦涩难懂，但不是有意而为之（因某些缘由，Perl 语言代码一般是这样的）。无论何时我看到那样的代码，我都会这样想： 把它想象成只有你破译它后才能学到的东西。是的，这是主要的痛楚之处，但要接受它，有时候你本身也会因琐碎的缘由而写出那种令人困惑的代码（否定没有用，你知道这是真的）。好了，若是你花些时间来阅读那样的代码，你更有可能最终写出一样的代码。并不说你将会写出那样的代码，但你有能力写出那样的代码。最后，态度一般是最重要的（编注：态度决定一切）。若是你视阅读代码为平常繁琐的工做，那它就是（繁琐的工做），而且你会逃避，但若是你视其为一个机遇，那好事终将到来。

 

注：本文转载自http://blog.csdn.net/sdulibh/article/details/38412955