logo资料库

如何读懂源代码!!!!.doc

第1页 / 共23页
第2页 / 共23页
第3页 / 共23页
第4页 / 共23页
第5页 / 共23页
第6页 / 共23页
第7页 / 共23页
第8页 / 共23页
资料共23页,剩余部分请下载后查看
如何看懂源代码--(分析源代码方法) 想要更多软件开发资料或帮助, 请加 QQ 技术群: 69255833 我们在写程序时,有不少时间都是在看别人的代 码。 例如看小组的代码,看小组整合的守则,若一开始 没规划怎么看, 就会“噜看噜苦(台语) ” 不管是参考也好,从开源抓下来研究也好,为了了 解箇中含意,在有限的时间下,不免会对庞大的源 代码解读感到压力。 网路上有一篇关于分析看代码的方法,做为程序设 计师的您,不妨参考看看, 换个角度来分析。 也能更有效率的解读你想要的 程序码片段。 六个章节: ( 1 )读懂程序码,使心法皆为我所用。 ( 2 )摸清架构,便可轻松掌握全貌。
( 3 )优质工具在手,读懂程序非难事。 ( 4 )望文生义,进而推敲组件的作用。 ( 5 )找到程序入口,再由上而下抽丝剥茧。 ( 6 )阅读的乐趣,透过程序码认识作者。 阅读他人的程序码( 1 ) ---读懂程序码,使心法 皆为我所用 程序码是别人写的,只有原作者才真的了解程序码 的用途及涵义。许多程序人心里都有一种不自觉的 恐惧感,深怕被迫去碰触其他人所写的程序码。但 是,与其抗拒接收别人的程序码,不如彻底了解相 关的语言和惯例,当成是培养自我实力的基石。 对大多数的程序人来说,撰写程序码或许是令人开 心的一件事情,但我相信,有更多人视阅读他人所 写成的程序码为畏途。许多人宁可自己重新写过一 遍程序码,也不愿意接收别人的程序码,进而修正 错误,维护它们,甚至加强功能。 这其中的关键究竟在何处呢?若是一语道破,其实 也很简单,程序码是别人写的,只有原作者才真的 了解程序码的用途及涵义。许多程序人心里都有一
种不自觉的恐惧感,深怕被迫去碰触其他人所写的 程序码。这是来自于人类内心深处对于陌生事物的 原始恐惧。 读懂别人写的程序码,让你收获满满 不过,基于许多现实的原因,程序人时常受迫要去 接收别人的程序码。例如,同事离职了,必须接手 他遗留下来的工作,也有可能你是刚进部门的菜 鸟,而同事经验值够了,升级了,风水轮流转,一 代菜鸟换菜鸟。甚至,你的公司所承接的专案,必 须接手或是整合客户前一个厂商所遗留下来的系 统,你们手上只有那套系统的原始码(运气好时, 还有数量不等的文件) 。 诸如此类的故事,其实时常在程序人身边或身上持 续上演着。许多程序人都将接手他人的程序码,当 做一件悲惨的事情。每个人都不想接手别人所撰写 的程序码,因为不想花时间去探索,宁可将生产力 花在产生新的程序码,而不是耗费在了解这些程序 码上。 很遗憾的是,上述的情况对程序人来说很难避免。
我们总是必须碰触到其他人所写成的程序码,甚至 必须了解它,加以修改。对于这项需求,在现今开 放原始码的风气如此盛行的今日,正如之前的“程序 设计 2.0 ”文中所提到的,你可以透过开放原始码 学习到新的技术,学习到高手的架构设计,大幅提 高学习的效率及效果。你甚至可以直接自开放原始 码专案中抽取,提炼出自己所需的程序码,站在巨 人的肩膀上,直接由彼端获得所需的生产力。从这 个观点来看,读懂别人所写的程序码,就不再只是 从负面观点的“被迫接收” ,而是极具正面价值的 “汲取养份。 ” 先了解系统架构与行为模式,再细读 倘若撰写程序码是程序人的重要技艺之一,那么读 懂别人的程序码,接着加以修改,也势必是另一个 重要的技艺。 如果你不能熟悉这项工作,不仅在遭逢你所不愿面 对的局面时,无法解决眼前接手他人程序码的难 题,更重要的是,当你看着眼前现成的程序码,却 不知如何从中撷取自己所需,导致最后只能入宝山 空手回,望之兴叹。
接触他人的程序码,大致上可以分为三种程度:一, 了解,二,修改,扩充,三,抽取,提炼。了解别 人的程序码是最基础的工作,倘若不能了解自己要 处理的程序码,就甭论修改或扩充,更不可能去芜 存菁,从中萃取出自己所需,回收再利用别人所撰 写的程序码。虽说是“阅读” ,但程序码并不像文章 或小说一样,透过这种做法,便能够获得一定程度 的了解。阅读文章或小说时,几乎都是循序地阅读, 你只消翻开第一页,一行行阅读下去即可。但是, 有许多程序人在试着阅读其他人的程序码时,却往 往有不知如何读起的困难。 或许找到系统的第一页(也就是程序码执行的启始 点)并不难,但是复杂度高的系统,有时十分庞大, 有时千头万绪。 从程序码的启始点开始读起,一来要循序读完所有 的程序码旷日费时,二来透过这种方式来了解系 统,很难在脑中构建出系统的面貌,进而了解到系 统真正的行为。所以,阅读程序码的重点,不在于 读完每一行程序码,而是在于有效率地透过探索及
阅读,从而了解系统的架构及行为模式。以便在你 需要了解任何片段的细节实作时,能够很快在脑上 对映到具体的程序码位置,直到那一刻,才是细读 的时机。 熟悉沟通语言与惯例用语 不论如何,有些基本的准备,是阅读他人程序码时 必须要有的。 首先,你最好得了解程序码写成的程序语言。想要 读懂法文写成的小说,总不能连法文都不懂吧。有 些情况则很特殊。我们虽然不懂该程序码撰写所用 的语言,但是因为现代语言的高阶化,而且流行的 程序语言多半都是血统相近,所以即使不那么熟 悉,有时也可勉力为之。 除了认识所用语言之外,再来就是要先确认程序码 所用的命名惯例(命名惯例) 。了解命名惯例很 重要,不同的程序人或开发团队,差异可能很大。 这命名惯例涵盖的范围通常包括了变数的名称,函 式的名称,类别(如果是物件导向的话)的名称,
原始码档案,甚至是专案建构目录的名称。倘若使 用了像设计模式之类的方法,这些名称更有一些具 体的表述方式。 命名惯例有点像是程序人在程序语言之上,另行建 构的一组沟通行话。程序人会透过共通约束,遵守 的命名惯例,来表达一些较高阶的概念。例如,有 名的匈牙利式命名法,便将变数名称以属性,型别, 说明合并在一起描述。对程序人来说,这种方式能 够提供更丰富的资讯,以了解该变数的作用及性 质。 对程序码阅读来说,熟悉这个做法之所以重要,是 因为当你了解整个系统所采用的惯例时,你便能试 着以他们所共同操用的语汇来进行理解。倘若,不 能了解其所用的惯例,那么这些额外提供的资讯, 就无法为你所用。像以设计模式写成的程序码,同 样处处充满着模式的名称,诸如:工厂,门面,代 理等等。以这些名称指涉的类别,也直接透过名称, 表达了它们自身的作用。对于懂得这命名惯例的读 者来说,不需要深入探索,也能很快捕捉到这些类 别的意义。
当你拿到一套必须阅读的程序码时,最好先取得命 名惯例的说明文件。然而,并不是每套程序码都附 有此类的说明文件。另一个方式,就是自己到程序 码中,大略浏览一遍,有经验的程序人可以轻易发 掘出该系统所用的命名惯例。 常见的命名方式不脱那几类,这时候经验就很重 要,倘若你知道的惯例越多,就越能轻易识别他人 所用的惯例。如果运气很糟,程序码所用的惯例是 前所未见的,那么你也得花点时间归纳,凭自己的 力量找出这程序码命名上的规则。 掌握程序码撰写者的心态与习惯 大多数的程序码,基本上都依循一致的命名惯例。 不过运气更差的时候,一套系统中可能会充斥着多 套命名惯例。这有可能是因为开发团队由多组人马 所构成,每组人马都有不同的文化,而在专案开发 管理又没有管控得宜所造成。最糟的情况,程序码 完全没有明显的惯例可言,这时候阅读的难度就更 高了。
分享到:
收藏