https://www.myziyuan.com/
- 亚亚
- 对于程序员来说，写代码永远比读代码来的舒服。但现实情况是，程序员常常需要阅读其他人员写的代码，更多的时候这些代码可能即没文档也没注释。不过，好象有个人说过一句话，代码之前，了无秘密。运用适当的策略可以让阅读工作变的轻松很多。1. 对于常用的系统函数进行追踪。比如ReadFile,CreateDevice,CreateWindow,在这些函数处放几断点，可以看到代码的调用过程。通过这种方式可以方便地把代码分为底层代码和上层逻辑代码。2.依据项目依赖关系进行阅读。项目的依赖关系同时表明了项目的复杂程度。对于大型的项目通常都会分割成若干子项目，根据项目的依赖关系，循序渐进的方式可以让阅读变的简单。3.对于以lib形式提供的子项目。在阅读时，可以先把lib的整个项目做为黑盒使用。根据_declspec(dllexport)或者以头文件方式提供的调用接口，可以减少对于细节的阅读时间。根据模块进行大致的划分，可以有效地对项目的结构有直接的感性认识。4.识别项目中使用的设计模式。对于大型项目来说，设计模式是必不可少的。在庞大的代码中识别设计模式，寻找代码中使用相似手法的代码结构可以极大简化需要阅读的代码。5.根据数据流程分析。动态职责划分。6.修改部分代码，进行调试。修改部分常数或者饶过某些程序执行流程，或者以简化的数据对程序进行追踪。
- 2021-02-23 17:25:02
- wydyaocg
- OpenStack 本身用 python 语言编写，虽然我一直觉得自己的 python 功底已经不错了，但在看源码的过程中，还总是觉得自己掌握的东西太少了，所以，首要的一点，如果你在看 OpenStack 源码，请一定要打牢你的 python 基础，不然有些技巧性的代码可能让你停滞不前。 看源码，如果能一气呵成最好。什么叫一气呵成呢？我先讲个每个人生活中都可能遇到的一些情况：你在做 A 事，但是突然 B 打电话，让你帮着解决 C 事，然后你就去做 C 事了，等你做完 C 事，发现家里有 D 事必须要做，然后你又去做 D 事……这样的结果就是，你把 A 事给遗忘了，即便你空闲时候想起来了，但是再去做的时候，发现没有第一次那样熟悉 A 事了，你需要重新花费一些时间来熟悉它。试想，如果一开始你就把 A 事做到底，会怎样？ 看源码其实是一个很漫长的过程，特别对一个大型项目而言，如果你要看完它的源码，过程是很曲折的，这里的看完不仅仅是过目了一遍，脑子里还要能把逻辑关系理顺。你可能有疑问了，要看源码，一天两天解决不了，但是又要保证一气呵成，这根本就是无稽之谈嘛！事情也的确是这样，鱼与熊掌不可兼得！这里就有一个技巧的问题了，你不妨想象，这么大一个项目，它是怎么开发出来的？难道一开始，项目就已经策划好了？需要多少个源文件，每个文件里面的源码是什么也都做好了？有点经验的程序员都知道，这是不可能的。项目的开发是慢慢细化的，一开始只是核心，然后是骨架，然后有血肉，然后有做 A 事的工具……到这里，或许你知道我要说什么了，源码怎么一步步写出来的，我们就怎么一步步的去看它。先研究核心，再研究骨架，然后血肉，其它工具……。还有一个问题，就算我知道怎么看这些源码，我怎么去一气呵成？这就好比你要完成一件大事情，但是你发现给自己定这么宏大的目标对自己来说比登天还难，所以你就想到用小目标来不断激励自己，最终不断接近大目标。这里的一气呵成既然不能一气把所有源码呵成，那就分段吧！不要心急，不要总想着还有很多源码都还没看，保持淡定！ 其实，看源码都是一样的，从架构处着手，然后慢慢扩展到细枝末叶。这里，说一些 utilities 。看源码是很枯燥的，一点都不形象不说，还要让脑子一直保持着源码中的很多东西，如果你想偷懒，如果你想让生活更简单，那就用图形吧，图形加速了整个 IT 的发展，它的强大与便利有目共睹。源码中的各个模块，类怎么耦合的，用了什么设计模式，拿张纸，画几笔，就显而易见了，当然，做个 PPT 更好。源码之间的互相交错是最让人头疼的，很多人一开始看源码，就从这个源文件的某个函数跳转到另一个源文件的某个函数，我想问一下，你以为你的大脑是电脑吗？你的大脑也可以像电脑那样按着调用顺序依次调用各个函数？？如果你在看一个源文件，OK，先把这个源文件一气呵成再说，不要跳转到其它源文件，如果引用的其它源文件中的函数你不知道是干嘛的，先 pass ，以后再说，只要你知道调用它的函数是干嘛的就行，等你以后研究到另外一个源文件的时候，这个关系就很明确了。还有一个现象，很多人一接触一个项目的源码，看见那么多源文件，一下子就懵了，不知道如何下手，别人说，从 main 开始看，于是，他就从 main 开始看了，其实这个无所谓，还是那句话，不要以为你的大脑是电脑，做一些人脑力所能及的事，随便找个源文件，然后用心去看它，不要觉得这里的随便就是随便，虽然它的确是随便，但是如果你不知道我说的随便是哪个随便，那就只有随便你了。不管哪个项目，源码包中大致结构一看，基本上就知道各个东西大致是干嘛的，开发这些东西的也是人脑，不是电脑，为了方便理解，基本上文件取名都还是见名知意的。看源码是一件很有挑战的事情，对源码而言，记住，你永远都要站在它的对面，而不是将自己深埋进源码中，一旦你钻进去了，你就已经迷失了自己。还有很多……（稍后补充） 上面说了那么多，都没有谈到 OpenStack ，其实这个是相辅相成的，上面的你知道了，看 OpenStack 你也应该没有问题了，OpenStack 的核心项目是 nova, glance, swift ，最核心的就是 nova 了，所以，从 nova 开始看吧。nova 源码包中有很多子包，源文件。除了版权版本以及和其它组件交互的东西，随便找一个开始看吧。切记，在开始看之前，最好能把你知道的 nova 架构图烂熟于心。 这个很重要，因为你之后随时有可能沉迷进源码大军中。 好了，文章到这里，基本上就结束了。貌似没有给冲着 OpenStack 源码来的读者一个很好的建议，其实，任何事都没有一蹴而就的方法，想做成它，最好的方法就是，保持淡定的心态，一步步，走下去！作为过来人，还是给个建议，从 虚拟化开始看，因为这个里面用到了适配器设计模式，你稍微看一点就知道了这个包是干嘛的了，而且，可以提升你继续看源码的信心。转载
- 2021-02-11 23:08:48
- 123qwe
- 如何阅读Flask源码,去年做过一个不大不小的Flask项目，这边分享下我的做法：读Flask源码确实需要读Werkzeug的源码，Jinja2的源码则可以先晾在一边，原因是在框架结构上Flask与Werkzeug结合的更紧些，例如我们在一次HTTP请求上下文中使用的request实例，就是通过Werkzeug的LocalProxy包装实现的。而Jinja2则完全集中在模板渲染上，如果题主目前的主要任务是理清“HTTP请求响应流”在框架代码中的走向，那么Jinja2部分可以先作为黑匣子。怎么切入，我认为最好的方法是在您的View Handler中用ipdb下一个断点，然后启动程序并在浏览器中访问该页面，当运行到断点时，Python进程那边已经切换到ipdb的调试模式，您可以通过步进并随时查看当前代码所处的文件、对应行数，以及当前的堆栈帧。第一次用ipdb下断点查看时，不需要在意当前到达的每一步位置的上下文代码，只要记住我在哪个文件的哪个函数（方法）中，这样一遍走下来，您对一次HTTP请求会依次经历Flask框架中的哪些部分有个初步印象。接下去，就是打开这些“框架部分”对应的源码文件进行宏观阅读了，这是第二步，如果有经验，能够凭直觉一眼看出（或通过方法名、或通过代码的自文档化）此处是在做什么。如果第一步用ipdb调试是在脑海中对框架打轮廓，那么第二步做完后，已经对这个框架实现有较为清晰、整体的认识了。第三步，根据第二步所建立的认识，继续使用ipdb打断点并调试，但在这次，需要仔细地“打量”当前上下文，例如上面说的查看堆栈帧、或者通过locals()、globals()查看当前名字空间的变化，第三步的作用是为第二步所建立的概念模型进行实践验证，以加强理解如此反复二三两步，对框架主要部分实现的认识则会愈加清晰，把握住框架主脉络后，对于其他模块，例如signals、session，则可以逐个击破了。另外，Flask还会直接依赖itsdangerous这个库，我认为也可以了解下。我现在还在看Flask源码，原因是它的文档字符串写得很棒，可以作为我在其他项目使用sphinx-doc组件实践时很好的模板:)。
- 2021-02-11 23:08:48
开通会员