如何看懂python代码分⼏步_如何看懂源代码--（分析源代码⽅
法）
在阅读程式码的细节之前，我们应先试着捕捉系统的运作情境。在采取由上⾄下的⽅式时，系统性的架构是最顶端的层次，⽽系统的运作情境，则是在它之下的另⼀个层次。
好的说明⽂件难求，拼凑故事的能⼒很重要
有些系统提供良善的说明⽂件，也许还利⽤UML的充分描述系统的运作情境。那么对于阅读者来说，从系统的分析及设计⽂件着⼿，便是快速了解系统运作情境的⼀个途径。
但是，并不是每个软体专案都伴随着良好的系统⽂件，⽽许多极具价值的开放原始码专案，也时常不具备此类的⽂件。对此，阅读者必须尝试⾃⾏捕捉，并适度地记录捕捉到的运作情境。
我喜欢将系统的运作情境，⽐拟成系统会上演的故事情节。在阅读细节性质的程式码前，先知道系统究竟会发⽣那些故事，是必备的基本功课。你可以利⽤熟悉或者⾃⼰发明的表⽰⼯具，描述你所到的情境。甚⾄可以只利⽤简单的列表，直接将它们列出。只要能够达到记录的⽬的，对程式码阅读来说，都能够提供帮助。或者，你也可以利⽤基于UML中的类别图，合作图，循序图之类的表⽰⽅法，做出更详细的描述。
当你能够列出系统可能会有的情境，表⽰你对系统所具备的功能，以及在各种情况下的反应，都具备概括性的认识。以此为基础，便可在任何需要的时候，钻进细节处深⼊了解。
探索架构的第⼀步─ ─到程式的⼊⼝
在之前，我们在⼀个开发专案中，曾经需要将系统所得到的的MP3⾳讯档，放⾄iPod的这个极受欢迎的播放设备中。
虽然iPod的本⾝也可以做为可移动式的储存设备，但并不是单纯地将MP3播放档案放到中的iPod ，就可以让苹果的播放器认得这个档案，甚⾄能够加以播放。
这是因为苹果利⽤⼀个特殊的档案结构( iTunes的数据库) ，记录播放器中可供播放的乐曲，播放清单以及乐曲资讯(例如专辑名称，乐曲长度，演唱者等) 。为了了解并且试着重复使⽤既有的程式码，我们到了⼀个AOL的Winamp的iPod的外挂程式(插件) 。
AOL的Winamp是个⼈电脑上极受欢迎的播放软体，⽽我们到的外挂程式，能让的软件直接显⽰连接⾄电脑的的iPod中的歌曲资讯，并且允许的软件直接播放。
我们追踪与阅读这个外挂程式的思路及步骤如下，⾸先，我们要先了解外挂程式的系统架构。很明显的，⼤概浏览过原始码后，我们注意到它依循着AOL的Winamp为插件程式所制定的规范，也就是说，
它是实作成的Windows上的DLL的，并且透过⼀个叫做winampGetMediaLibraryPlugin的DLL的函式，提供⼀个名为winampMediaLibraryPlugin的结构。
当我们不清楚系统的架构究竟为何时，我们会试着探索，⽽第⼀步，便是到程式的⼊⼝。如何到呢？这会依程式的性质不同⽽有所差别。
对⼀个本⾝就是可独⽴执⾏的程式来说，我们会启动程式的主要函式，例如对的C / C + +来说就是主要( ) ，⽽对⽖哇来说，便是静⽆效的main ( ) 。在到⼊⼝后，再逐⼀追踪，摸索出系统的架构。
但有时，我们所欲阅读的程式码是类别库或函式库，它只是⽤来提供多个类别或函式供⽤户端程式(客户程序)使⽤，本⾝并不具单⼀⼊⼝，此类的程式码具有多重的⼊⼝─ ─每个允许⽤户端程式呼叫的函式或类别，都是它可能的⼊⼝。
例如，对AOL的Winamp的iPod的插件来说，它是⼀个动态链接库形式的函式库，所以当我们想了解它的架构时，必须要先出它对外提供的函式，⽽对的Windows的DLL来说，对外提供的函式，皆会以dllexport这个关键字来修饰。所以，不论是利⽤grep按或gtags之类的⼯具，我们可以很快从原始码中，到它只有⼀个DLL的函式(这对我们⽽⾔，真是⼀个好消息) ，⽽这个函式便是上述的winampGetMediaLibraryPlugin 。
系统多会采⽤相同的架构处理插件程式 如果经验不够的话，也许⽆法直接猜出这个函式的作⽤。
不过，如果你是个有经验的程式⼈，多半能从函式所回传的结构，猜出这个函式实际的⽤途。⽽事实上，当你已经知道它是⼀个插件程式时，就应该要明⽩，它可能采⽤的，就是许多系统都采⽤的相同架构处理插件程式。
当⼀个系统采⽤所谓插件形式的架构时，它通常不会知道它的插件究竟会怎么实作，实作什么功能。它只会规范插件程式需要满⾜某个特定介⾯。当系统初始化时，所有的插件都可以依循相同的⽅式，向系统注册，合法宣⽰⾃⼰的存在。
虽然系统并不确切知道插件会有什么⾏为展现，但是因为它制定了⼀个标准的介⾯，所以系统仍然可以预期每个插件能够处理的动作类型。这些动作具体上怎么执⾏，对系统来说并不重要。这也正是物件导向程式设计中的“多型”观念。
随着实务经验，归纳常见的架构模式
我想表达的重点，是当你“涉世越深”之后，所接触的架构越多，就越能触类旁通。只需要瞧上⼏眼，就能明⽩系统所⽤的架构，⾃然就能够直接联想到其中可能存在的⾓⾊，以及⾓⾊间的关系。
像上述的插件程式⼿法，时常可以在许多允许“外挂”程式码的系统中看到。所以，有经验的阅读者，多半能够⽴即反应，知道像这样的系统的软件，应该是让每个插件程式，都写成DLL的函式库。
⽽每个插件的DLL的函式库中，都必须提供winampGetMediaLibraryPlugin ( )这个函式(如果你熟悉的Windows的程式设计，你会知道这是利⽤加载( )和GetProcAddress ( )来达成的⼀种多型⼿法) 。如果你熟悉设计模式，你更会知道这是简单⼯⼚⽅法这个设计模式的运⽤。
winampGetMediaLibraryPlugin ( )所回传的winampMediaLibraryPlugin结构，正好就描述了每个AOL的Winamp插件的实作内容。python怎么读的
善⽤名称可加速了解
利⽤gtags这个⼯具，我们⽴即发现，这个插件它所定义的初始化，退出， PluginMessageProc这三个名称，都是函式名称。这暗⽰在多型的作⽤下，它们都是在某些时间点，会由AOL的Winamp核⼼本体呼叫的函式。
名称及命名惯例是很重要的。看到“初始化” ，我们会知道它的作⽤多半是进⾏初始化的动作，⽽“退出”⼤概就是结束时处理函式，⽽PluginMessageProc多半就是各种讯息的处理常式(过程通常是程序的简写，所以PluginMessageProc意指插件讯息程序)了。
“望⽂⽣义”很重要，我们看到函式的名称，就可以猜想到它所代表的作⽤，例如：当AOL的Winamp尝试着初始化⼀个插件时，它会呼叫这个结构中的初始化函式，以便让每个插件程式有机会初始化⾃⼰；
当AOL的Winamp打算结束⾃⼰或结束某个插件的执⾏时，便会呼叫退出函式。当AOL的Winamp要和插件程式沟通时，它会发送各种不同的讯息⾄插件，⽽插件程式必须对此做出回应。
我们甚⾄不需要检视这⼏个函式的内容，就可以做出推测，⽽这样的假设，事实上也是正确的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。