如何看程序源码 ->附链接

http://wenku.baidu.com/link?url=XvgINGwdvgu5ZqxYB6xNDT_ngbb4RkEOs-H8MTnvJRzfGRFemh-8Pp97LQGNAld0NeD3xIn-zYR0rvZu7xt35XjaIln2mhHEkmsZqPQO1Tq

如何看程序源码

 

不管是参考也好，从开源抓下来研究也好，为了了解箇中含意，在有限的时间

下，不免会对庞大的源代码解读感到压力。

 

 

网路上有一篇关于分析看代码的方法，做为程式设计师的您，不妨参考看看，

 

 

换个角度来分析。

 

也能更有效率的解读你想要的程式码片段。

 

 

六个章节：

 

  

（

 

1 

）读懂程式码，使心法皆为我所用。

 

 

（

 

2 

）摸清架构，便可轻松掌握全貌。

 

 

（

 

3 

）优质工具在手，读懂程式非难事。

 

  

（

 

4 

）望文生义，进而推敲组件的作用。

 

  

（

 

5 

）找到程式入口，再由上而下抽丝剥茧。

 

  

（

 

6 

）阅读的乐趣，透过程式码认识作者。

 

如何看程序源码

 

不管是参考也好，从开源抓下来研究也好，为了了解箇中含意，在有限的时间

下，不免会对庞大的源代码解读感到压力。

 

 

网路上有一篇关于分析看代码的方法，做为程式设计师的您，不妨参考看看，

 

 

换个角度来分析。

 

也能更有效率的解读你想要的程式码片段。

 

 

六个章节：

 

  

（

 

1 

）读懂程式码，使心法皆为我所用。

 

 

（

 

2 

）摸清架构，便可轻松掌握全貌。

 

 

（

 

3 

）优质工具在手，读懂程式非难事。

 

  

（

 

4 

）望文生义，进而推敲组件的作用。

 

  

（

 

5 

）找到程式入口，再由上而下抽丝剥茧。

 

  

（

 

6 

）阅读的乐趣，透过程式码认识作者。

 

  

  

  

  

  

阅读他人的程式码（

 

1 

）

 

---

读懂程式码，使心法皆为我所用

 

  

  

  

程式码是别人写的，只有原作者才真的了解程式码的用途及涵义。许多程式人

心里都有一种不自觉的恐惧感，深怕被迫去碰触其他人所写的程式码。但是，

与其抗拒接收别人的程式码，不如彻底了解相关的语言和惯例，当成是培养自

我实力的基石。

 

 

  

对大多数的程式人来说，撰写程式码或许是令人开心的一件事情，但我相信，

有更多人视阅读他人所写成的程式码为畏途。许多人宁可自己重新写过一遍程

式码，

也不愿意接收别人的程式码，

进而修正错误，

维护它们，

甚至加强功能。

 

  

  

这其中的关键究竟在何处呢？若是一语道破，其实也很简单，程式码是别人写

的，只有原作者才真的了解程式码的用途及涵义。许多程式人心里都有一种不

自觉的恐惧感，深怕被迫去碰触其他人所写的程式码。这是来自于人类内心深

处对于陌生事物的原始恐惧。

 

  

  

读懂别人写的程式码，让你收获满满

 

  

不过，基于许多现实的原因，程式人时常受迫要去接收别人的程式码。例如，

同事离职了，必须接手他遗留下来的工作，也有可能你是刚进部门的菜鸟，而

同事经验值够了，升级了，风水轮流转，一代菜鸟换菜鸟。甚至，你的公司所

承接的专案，必须接手或是整合客户前一个厂商所遗留下来的系统，你们手上

只有那套系统的原始码（运气好时，还有数量不等的文件）

 

。

 

  

  

诸如此类的故事，其实时常在程式人身边或身上持续上演着。许多程式人都将

接手他人的程式码，当做一件悲惨的事情。每个人都不想接手别人所撰写的程

式码，因为不想花时间去探索，宁可将生产力花在产生新的程式码，而不是耗

费在了解这些程式码上。

 

  

  

很遗憾的是，上述的情况对程式人来说很难避免。我们总是必须碰触到其他人

所写成的程式码，甚至必须了解它，加以修改。对于这项需求，在现今开放原

始码的风气如此盛行的今日，

正如之前的

“

程式设计

2.0

 

”

文中所提到的，你可以

透过开放原始码学习到新的技术，学习到高手的架构设计，大幅提高学习的效

率及效果。你甚至可以直接自开放原始码专案中抽取，提炼出自己所需的程式

码，站在巨人的肩膀上，直接由彼端获得所需的生产力。从这个观点来看，读

懂别人所写的程式码，就不再只是从负面观点的

“

被迫接收

” 

，而是极具正面价

值的

“

汲取养份。

 

” 

  

 

 

先了解系统架构与行为模式，再细读

 

 

 

倘若撰写程式码是程式人的重要技艺之一，那么读懂别人的程式码，接着加以

修改，也势必是另一个重要的技艺。

 

  

  

如果你不能熟悉这项工作，不仅在遭逢你所不愿面对的局面时，无法解决眼前

接手他人程式码的难题，更重要的是，当你看着眼前现成的程式码，却不知如

何从中撷取自己所需，导致最后只能入宝山空手回，望之兴叹。

 

  

  

接触他人的程式码，大致上可以分为三种程度：

一，了解，二，修改，扩充，

三，抽取，提炼。

了解别人的程式码是最基础的工作，倘若不能了解自己要处

理的程式码，就甭论修改或扩充，更不可能去芜存菁，从中萃取出自己所需，

回收再利用别人所撰写的程式码。虽说是

“

阅读

” 

，但程式码并不像文章或小说

一样，透过这种做法，便能够获得一定程度的了解。阅读文章或小说时，几乎

都是循序地阅读，你只消翻开第一页，一行行阅读下去即可。但是，有许多程

式人在试着阅读其他人的程式码时，却往往有不知如何读起的困难。

 

  

  

或许找到系统的第一页（也就是程式码执行的启始点）并不难，但是复杂度高

的系统，有时十分庞大，有时千头万绪。

 

  

  

从程式码的启始点开始读起，一来要循序读完所有的程式码旷日费时，二来透

过这种方式来了解系统，很难在脑中构建出系统的面貌，进而了解到系统真正

的行为。所以，阅读程式码的重点，不在于读完每一行程式码，而是在于有效

率地透过探索及阅读，从而了解系统的架构及行为模式。以便在你需要了解任

何片段的细节实作时，能够很快在脑上对映到具体的程式码位置，直到那一刻，

才是细读的时机。

 

  

  

熟悉沟通语言与惯例用语

 

  

不论如何，有些基本的准备，是阅读他人程式码时必须要有的。

 

  

  

首先，你最好得了解程式码写成的程式语言。想要读懂法文写成的小说，总不

能连法文都不懂吧。有些情况则很特殊。我们虽然不懂该程式码撰写所用的语

言，但是因为现代语言的高阶化，而且流行的程式语言多半都是血统相近，所

以即使不那么熟悉，有时也可勉力为之。

 

  

  

除了认识所用语言之外，再来就是要先确认程式码所用的

命名惯例

（命名惯

例）

 

。了解命名惯例很重要，不同的程式人或开发团队，差异可能很大。

 

  

这命名惯例涵盖的范围通常包括了变数的名称，函式的名称，类别（如果是物

件导向的话）的名称，原始码档案，甚至是专案建构目录的名称。倘若使用了

像设计模式之类的方法，这些名称更有一些具体的表述方式。

 

  

  

命名惯例有点像是程式人在程式语言之上，另行建构的一组沟通行话。程式人

会透过共通约束，遵守的命名惯例，来表达一些较高阶的概念。例如，

有名的

匈牙利式命名法，便将变数名称以属性，型别，说明合并在一起描述

。对程式

人来说，这种方式能够提供更丰富的资讯，以了解该变数的作用及性质。

 

  

  

对程式码阅读来说，熟悉这个做法之所以重要，是因为当你了解整个系统所采

用的惯例时，你便能试着以他们所共同操用的语汇来进行理解。倘若，不能了

解其所用的惯例，那么这些额外提供的资讯，就无法为你所用。像以设计模式

写成的程式码，同样处处充满着模式的名称，诸如：工厂，门面，代理等等。

以这些名称指涉的类别，也直接透过名称，表达了它们自身的作用。对于懂得

这命名惯例的读者来说，不需要深入探索，也能很快捕捉到这些类别的意义。

 

  

  

当你拿到一套必须阅读的程式码时，最好先取得命名惯例的说明文件。然而，

并不是每套程式码都附有此类的说明文件。另一个方式，就是自己到程式码中，

大略浏览一遍，有经验的程式人可以轻易发掘出该系统所用的命名惯例。