阅读代码

0

IT/互联网视点

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

2 评论 

[发表人]： 

关关

 [发表时间]：2011-01-24 10:23 AM

　　编者按：原文作者Alan Skorkin是一名软件开发人员，他在博客中分享对软件开发相关的心得，其中有很多优秀的文章，本文是其中的另一篇。Alan认为： 阅读优秀代码是提高开发人员修为的一种捷径。以下是全文。

　　我突然想起来，很多程序员都讨厌阅读代码。来吧，承认吧！ 每个人都喜欢编写代码，编代码是件趣事。 另一方面，阅读代码也不容易。 不仅不容易（编注：参见《 微软资深软件工程师：阅读代码不容易》），而且还非常枯燥，咱们要面对这一事实。任何不是你的代码都不怎样。（虽然我们没有说出来，但我们都是这样想的。） 即便是你自己几个小时之前写的代码，也会看起来很烂。时间越久，看起来越烂。 所以，为什么你要浪费时间去看其他人的糟糕代码，而你完全可以利用这段时间编写你自己的优秀代码。 其实我们可以一试，几个小时之后回头再看，看看你的代码是否还依旧优秀。 如果你不能吸收前辈大师的经验知识，那你永远都无法成为一位大师。 成为大师的方法之一是，找到一位大师，让其倾囊传授其所知。 有这种可能么？当然了，有这可能，虽然机会不大，但你必须极其走运。 不过你不必十分走运，因为我们幸运地处于这样一个职业，一个充满着大师知识和技能的职业，等待我们去汲取吸收，这些东西就在他们所编写的代码中。 你要做的就是去阅读代码，当然了，这或许耗时不少，毕竟没有人坐在那里给你讲解，但这种方法的成效还很高。 打个比方，要想成为一名卓越的木匠，得观察大量结构优良的家具。

　　我喜爱阅读代码，我的直觉告诉我，你也会从中获益颇丰。虽然阅读过程恼人并烦人，但其回报是非常值得你为之努力的。 说到这个，如果你想成为一名卓越的作家，你会专注于写作么？ 你或许已经尝试，但你并没有走得很远。 大多数的伟大作家也是如饥似渴的读者，这是一个普遍事实。 在你能写出任何拿得出手的东西之前，你需要品读其他伟大作家，吸收不同的风格，看看前辈已尝试过的东西，从中吸取精华。 你的知识会慢慢增长，你自己的作品最终会透露出些许成熟，你也会找到一种“感觉”。 编写代码和写作没什么不同，如果你都没有阅读过任何卓越的代码，你为什么期望自己能写出像样的代码呢？ 你显然不应该那样。对于程序员来说，阅读卓越代码就如同作家阅读优秀书籍一样重要（这话可不是我说的，这是 Peter Norvig（Google研究院总监）说的，他非常优秀，大家也要向他学习了）。

　　即便所有这些都无法让你信服，那这里有一个不可置否的事实。 对你作为一名专业开发人员的生存来说，善于阅读代码至关重要。 如今，任何有一定规模的项目，都是团队的成果。所以，你通常要处理、修改和扩展大量不是你写的代码。 因此，阅读代码可能是你能掌握的最常用并最有用的技能。挺过这个难关，好好掌握。


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

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

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

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

• 3. 确信自己理解所有结构。 除非你碰巧是所用编程语言的首席专家，否则该语言有些它能做的事你可能还不知道。当你在浏览代码时，记下所有你或许不熟悉的结构。 如果有很多不熟悉的结构，你要做的下一步非常明显。 如果你不知道代码要做什么，那你就走不了很远。 即便只有几个你不熟悉的结构，你应当深入查看。 你现在是在探索你所用编程语言中你以前不知道的东西，为此花几个小时来阅读代码，我也非常乐意。

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

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

• 6. 如果你说没有测试，那这听起来是编写测试的时候了。 （编写测试）有很多益处，有助于你自己的理解，有助于你提升代码库，阅读代码时也能编写代码，这是该你出手做些事的时候。 即便已经有了测试，通常你也可以编写一些测试，你总能受益的。 测试代码通常需要换种方式思考问题，那些你以前不太明了的概念也会变得更清晰。

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

• 8. 代码不干净？有异味？ 为什么不重构它？ 我并不建议你重写整个代码库，但重构部分代码，真的有助于你理解层次上升一层。 把你理解的函数拿出来，改成独立的函数。 在你知道之前，原来的大函数看起来易管理，你可以在脑海中修改它。 重构允许你把代码变成自己的，无需完成重写代码。 如果有好的测试，有助于重构，但即便你没有好的测试，抽取你确定的函数并做测试。 即便测试看起来完全不充分，但作为一个开发人员，你得学着相信你的技能，有时候你只需努力去做（重构）。（如果你必须重构，你通常都可以把代码恢复原状。）

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

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


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


　　我们喜欢编写新代码，是因为我们这次能正确处理问题。 好吧，也许不是这次，但一定是下次。 事实上是，你经常改进你的技术，但你从没有恰当地处理问题。 这就是编写新代码的价值所在，你可以历练并磨练你的技能，但阅读和把玩其他人编写的代码，（如果没有更多的价值，）也是有同样多的价值。 你不仅能从中获得一些有价值的技术知识，也能收获领域知识，领域知识通常仍具更多价值（毕竟，代码是文档的最终形式）。

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

　　 编者后话

　　你会经常去阅读优秀的开源代码么？欢迎在评论中和大家分享。

 

 

 

 

• 1. 一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码 — —不管他的技术水平有多高。 好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。“一个卓越的车床工可以要求比一个一般的车床工多拿数倍高的工资，但一个卓越的软件写手的价值会10000倍于一个普通的写手。”——比尔 盖茨

• 2. 一个优秀的程序员的效率会是一个普通的程序员的十倍之上。一个伟大的程序员的效率会是一个普通程序员的20-100倍。这不是夸张 — — 1960年以来的无数研究都一致的证明了这一点。一个差的程序员不仅仅是没效率 — — 他不仅不能完成任务，写出的大量代码也让别人头痛的没法维护。

• 3. 伟大的程序员只花很少的时间去写代码——至少指那些最终形成产品的代码。那些要花掉大量时间写代码的程序员都是太懒惰，太自大，太傲慢，不屑用现有的方案去解决老问题。伟大的程序员的精明之处在 于懂得欣赏和重复利用通用模式。好的程序员并不害怕经常的重构（重写）他们的代码以求达到最好效果。差的程序员写的代码缺乏整体概念，冗余，没有层次，没 有模式，导致很难重构。把这些代码扔掉重做也比修改起来容易。

• 4. 软件遵循熵的定律，跟其它所有东西一样。持续的变更会导致软件腐烂，腐蚀掉对原始设计的完整性概念。软件的腐烂是不可避免的，但程序员在开发软件时 没有考虑完整性，将会使软件腐烂的如此之快，以至于软件在还没有完成之前就已经毫无价值了。软件完整性上的熵变可能是软件项目失败最常见的原因。（第二大 常见失败原因是做出的不是客户想要的东西。）软件腐烂使开发进度呈指数级速度放缓，大量的软件在失败之前都是面对着突增的时间要求和资金预算。

• 5. 2004年的一项研究表明大多数的软件项目（51%）会在关键功能上失败，其中15%是完全的失败。这比1994年前有很大的改进，当时是31%。

• 6. 尽管大多数软件都是团体开发的，但这并不是一项民/主的活动。通常，一个人负责设计，其他人负责实现细节。

• 7. 编程是个很难的工作。是一种剧烈的脑力劳动。好的程序员7×24小时的思考他们的工作。他们最重要的程序都是在淋浴时、睡梦中写成的。因为这最重要的工作都是在远离键盘的情况下完成的，所以软件工程不可能通过增加在办公室的工作时间或增加人手来加快进度。