概述：专业程序员非常重要的一项技能是读别人写的代码，这项技能甚至比自己写代码更重要。

分析：

　　这让我想到很多程序员讨厌去阅读代码，来接受它吧。人人都喜欢编写代码--写代码是很有乐趣的事。但阅读代码却是一种困难的工作。它不仅仅繁重，而且很无聊，让我们面对这个事实，任何不是自己写的代码都是差劲的（嘿嘿，虽然我们没有这样说过，但是其实我们都是这样想 的）。甚至当你写完代码后的仅仅几个小时之后，你的那些代码就开始变得越来越烂了，时间一长，你就会把它当作看起来的那种差劲作品。

　　所以，你又何必要去花费时间来审视别人蹩脚的代码呢，这段时间你完全可以用来 自己去写一些非常优秀的代码，为什么不这样尝试一下，把自己写好的代码放上几个小时再回头看看，它是否依旧非常优秀呢？如果你不站在前辈们的肩膀上，你将没有可能成一个为技艺精湛的大师。其中一种途径就是亲自找到一个大师，让他把他所有的知识全部传授给你--当然这是有可能的，虽然可能性不高，你必须非常走运才能获到这种机会。然而你可以不用想着去碰运气， 我们很幸运的处在这样的一个职业里--大师们的经验和知识都在那里等着我们去吸收，这些都蕴涵在他们所写 的代码里。你所要做的事就是去阅读它，当然它可能会比找一个人坐在你旁边向你解释这些多占用一点时间，但是这是实现起来可能性较高，透视全局地思考下，若想成为优秀的木匠，你就必需观察大量的拥有优良结构的家具。

　　……

　　【未完】更精彩的内容进作者的空间去看吧 >>> [译文]为何我喜爱读他人的代码，而你也应该去喜爱它

以下为两位笔者分享的一些经验，借来展示一下：

标题：说说我对阅读源代码的一些技巧方法，其实这并不难。
作者：afadgaeg
原文：http://afadgaeg.javaeye.com/blog/264490
正文：

　　阅读源代码的利弊我不谈，我只说该如何读.

　　首先是积累，当到了一定条件，你会迫不及待的想要去读，因为你想拥有程序的控制权 .

　　我把一份陌生的源代码比做一个陌生的城市，你将在里面熟悉道路，你只要从一个大的标志开始进入（程序入口点）然后你面临很多分支，有的分支很明显的（依靠设计模式，oo，模块化，结构化，解耦，经验判断，当然还有文档，注释，别人的源码分析文章）与其它没有什么瓜葛，或者只有几个联系点，其实是一个模块化功能，就像你知道有一条路通向xx村，你先不管它，知道它通哪里就可以了，以后再专程访问xx村。

　　一个设计优良的程序肯定是一个个通过乡村高速公路连接的村落，而不该是交杂在一起的钢筋水泥，至不济也该是用围墙围起来的一个个小区。

　　当你知道并熟悉了城市的主干道之后，整个城市其实已经成竹在胸了

　　你该学好模式，oo，模块化，结构化，解耦，接口，多态。。。。
广义来说就是oo

　　写给初学的人，以让他们少走不成器的我走过的弯路。

　　补充一条找源码分析文章的技巧>>> <b>在google中输入关键的源码片段</b>

　　补充一点经验：

　　当你读过一些模块之后，看到类似的模块就会下意识的去猜测该模块内部的代码结构，如果你读的够多，实践够丰富，模块就了然于胸了。

　　比如看到一个方法名，根据方法的字面意思就能猜测出该方法的代码结构，看到类名，就可能会猜测出它该要有什么方法。 这时读代码的速度就快了。

　　代码是一个有机体，当你具有把一份源代码解构成一个有机体的能力的时候，读代码其实并不痛苦。可是我还没有达到我想像的哪个层次。

 

标题：如何读代码？
作者：卢声远<michaellufhl@yahoo.com.cn>
原文：http://blog.csdn.net/michaellufhl/archive/2010/10/09/5930570.aspx
正文：

　　有時候在察看开源項目的時候，如果你想參與其中，那項目的负責人基本上都是建议从bugfix開始了解程序，了解代码。所以第一个建议就是从bugfix和添加新功能入手 。事實上在公司參加一個新項目的开发或者维护也大多是從bugfix入手。這樣入手的好處在於可以集中精力去了解以小块代码的運作機制。显然這很符合人的思維規律-做简单的事情总比做复杂的事情來得容易和高效。当然這不是盲人摸象，要bugfix的話至少自己要知道整個軟件的功能和層次，这需要閲读文檔而不是代码。

　　说到注释，这个时候就太有用了。不用说是别人写的代码，就是自己几个月前写的代码自己也需要仔细看一下才能搞懂。但是残酷的现实就是注释很少，更残酷的现实是越是低质量的代码，它的注释越是少。怎么办？只能猜 了。如果我们碰到一个很长的方法，但是我们需要跳过去看调它的代码，我们就需要猜测这个方法的功能了。然后再回过头来仔细看那个方法。我们可以运气好的话作者会取很合理的class名，method名和变量名。其实里面有个矛盾：很复杂，内聚很松散的method或者class，它们的名字就根本不可能取得合理。这个道理很简单，一个method里面做了很多事情，你就很难给它取一个合适的名字。像removeUserAndItsClientsAndUpdateTime()， 或者干脆来个缩写removeUCUpdateT()。 这样的名字基本没有可读性。

　　还有就是读上层 和读下层 。读上层就是在代码的 高层阅读，碰到底层的API可以猜出它的作用。这样把一块高层的代码像读逻辑那样粗线条梳理清楚，其实就是一大块一大块地读代码。读下层就是把底层的代码if else一一读懂。这两者缺一不可。

　　碰到很乱的代码几乎只能利用IDE debug, step by step 得一行一行执行。因为乱，所以没有仔细看整体结构的必要，而最有效的就是step by step了。当然有些时候程序逻辑必须依赖数据库或者外部数据，这样的话光看代码也不行。也只能step by step或者运行时log。

　　在OO的时代design pattern也已经深入人心。在看高质量代码的时候会发现他们的代码有个特点就是相当抽象，或者说面向抽象。里面有很多interface, abstract class, 还有anonymous class, 很长的继承链。我认为既然作者写程序的时候面向抽象，那么我们读程序的时候也要面向抽象 。我们经常在读代码察看某个变量的时后用IDE的查看功能点进去，然后发现它是一个接口全无实现。很多时候我们的第一反应就是找到具体的实现类，我倒是认为可以关注这个接口先往下读代码，然后回过头来看实现。既然作者的意图就是让接口来工作，我们就可以先了解作者的意图来看代码。顺便说来，要读懂很抽象的代码，读者自己首先要有很好的OO概念和design pattern的知识。

　　精彩文章推荐：今年程序员们解决问题的顺序