阅读他人的项目源代码步骤
备份并编译运行代码
熟悉项目编程语言的语法和惯例用语
看项目文档，有机会可向项目开发人员请教
自上而下构建项目程序的系统架构
建立系统架构和功能逻辑之间的关联
核心代码重点剖析与注释
调整心态，反复阅读
工欲善其事，必先利其器
揣摩作者的编程习惯与思想
相信很多人和我一样，面对着别人密密麻麻的代码，宁愿自己从零开始编写自己的代码，也不愿在别人代码的基础上修改： 阅读别人的代码太痛苦了! 在注释不明确、技术文档缺失，这一行行的代码犹如阅读天书一般，痛苦、煎熬，迷茫。因此，对于阅读别人的代码，我从内心有一种强烈的抵制情绪，甚至有些恐惧。
然而，阅读他人的项目源码是每一个写程序的人（我只是个在项目需要的时候偶尔写程序的，不敢自称程序员）必须经历的事情。也许我们想提升自己的编程技能，学习他人优秀的编程风格，那阅读优秀的项目代码是毕竟的途径；也许我们要研究某方面的功能或技术，那如果某个项目源码中已经有该技术或者功能的实现，根据源码“逆向工程”也是个方法；也许我们需要被迫接手别人未完成的项目，需要在别人已完成部分的基础上实现功能的修改或则项目的移植，阅读他人源码则关系到我们吃饭的本领。恩，我就是属于第三种，为了移植别人项目中的功能而被迫硬着头皮去阅读已有的代码。为了让自己坚持下去，我逐渐说服自己要乐于从阅读他人代码中学习，你看，阅读他人代码的好处多多呀/微笑脸。与其在内心中一直抗拒阅读他人代码，不如改变自己的心态，锻炼自己阅读他人代码的能力和技巧，用熟练的方法和套路提高阅读他人源码的体验。
我认为生活中遇到的绝大多数事情都可以总结出一种比较高效做事方法，或者叫套路，在阅读他人项目源码这件事情上也不例外。在看了一个月代码的基础上，综合前辈们的经验和自己的亲身体会，总结出了一套比较高效地阅读他人项目源代码的方法，如果你感觉叫套路或者方法有点儿太low，咱可以改头换面叫艺术。在我们遵循这种方法去阅读代码时，一般都会取得事半功倍的结果，希望自己今后能不断实践并优化这套方法，也希望能对正因阅读他人代码而苦恼的你有所帮助。
备份并编译运行代码
拿到项目源代码之后，首先应该对代码进行备份，因为很可能我们在哪儿就不小心改动了代码，养成备份的好习惯是很重要的。然后我们可以在IDE中编译运行，虽然看不到项目的细节，但是通过运行程序，我们会对程序的功能和运行过程有更加直观的认识。同时，编译运行的过程会让你了解到它使用的库、它所依赖的开发框架等等，这是提高我们对某个特定项目理解的好方法。如果我们想编写与正在探究的特定项目类似的自己的软件，可能会对我们应该使用的框架或库有一些想法。
熟悉项目编程语言的语法和惯例用语
我们要对项目代码的编程语言有一定的了解，想要读英文小说，起码应该学习一下英语单词和语法吧。每种语言都有自己的一套约定、样式和语法，深入了解某个特定语言有助于提高代码阅读技能。同时，我们要熟悉这种语言编程的一些惯例，例如基本的命名原则。我们知道命名一般有驼峰法、匈牙利命名法、帕斯卡命名法，倘若我们熟悉这戏命名原则，则很容易辨别出所阅读代码的命名方式，那么后面阅读的时候通过变量和函数的名字我们就可以获得比较丰富的信息。因此，在拿到代码后，首先要找一下是否有程序命名范例说明，没有的话自己根据代码总结出命名规则，这对后续提高阅读速度是十分有帮助的。
看项目文档，有机会可向项目开发人员请教
公司的项目代码一般都会有相关的设计文档，描述项目的设计过程和基本的内容框架，通过这些文档，我们对项目可以有个整体的认识，比如项目分为几个模块儿，各有什么功能？使用了什么开源库？在代码看到一定程度后，可以带着问题和自己的理解去想项目的开发人员请教，因为他们对代码的熟悉程度比我们强，比自己在那憋着瞎猜代码的含义要高效得多？再说，你帮我下，我帮你下，一来一回还能增加感情呢~但是注意一定是带着问题和自己的理解去沟通交流，否则啥都没看就去问，很容易招致他人的反感。
自上而下构建项目程序的系统架构
阅读代码很容易陷入一个误区：刚开始就企图把所遇到的每一行程序都搞明白其功能和实现。一叶障目，不见泰山。过于纠结具体的实现细节会在最开始就把我们陷于泥潭之中而不能前进，浪费时间并消磨我们阅读代码的耐心和信心。相反，在最开始时我们应该专注于掌握项目程序的系统架构，根据其模块儿划分和调用逻辑在脑海里构建其骨架，即要知道它先干嘛、再干嘛，为了干这个需要与哪些模块儿进行什么交互，从宏观上对项目有一个全面的认识。为了弄清其架构，我们可以采取top-down的方法，一般可以从其主函数出发，一般是main()函数或者其他函数，然后顺着项目程序的主要功能这个线索一路走下去，根据函数的名字以及层次关系确定每一个函数的大致用途即可，将理解作为注解写在这些函数的边上，不用关注这些函数的具体实现。在阅读时，要利用uml建立各类对象之间的关系，并根据自己要展开的层级，随手在笔记本上绘制出树状结构，忽略对系统架构不重要的细节，逐渐建立该项目代码的系统架构。注意在该步骤中一定要注意展开的层级，这涉及到这部分工作量的问题，究竟需要展开到那一层，需要根据我们的系统架构定位有关，要看我们所希望的系统架构具体到哪一个层次。
建立系统架构和功能逻辑之间的关联
在完成系统架构的搭建之后，我们需要根据程序功能，理解系统架构中每一部分的功能，以及其和其他部分的逻辑交互。这一步对于我们进一步理解系统架构的逻辑，以及后面对每个功能模块儿详细功能的深入探究是很重要的。这个过程与上一个过程有重叠的部分，在对应完每部分的功能之后，我们要对整个系统功能进行模拟逻辑推理，确定我们猜测的各模块儿的功能是合理的。
核心代码重点剖析与注释
完成系统架构搭建之后，需要转入bottom-up这一部分是我们理解程序某一个程序功能的重要过程，使我们阅读代码的核心之一。此时我们应该要逐行进行阅读，搞清楚每个语句的功能和实现方法，搞清变量的意义和关联关系，搞清实现的逻辑和算法。从我们最感兴趣的一个点，开始设置断点，跟进去看发生了哪些事情，这一块儿和架构设计哪一块是match的。然后就是阅读过程中注释的书写了，这是加深程序理解的重要方法。
基本原则是：
猜测的去写，刚开始阅读一个代码的时候，很难一下子就确定所有的函数的功能，不妨采用采用猜测的方法去写注解，根据函数的名字、位置写一个大致的注解，当然一般会有错误，但你的注解实际是不断调整的，直到最后你理解了全部代码。
按功能去写，别把注解写成语法说明书，千万别看到fopen就写打开文件，看到fread就写读数据，这样的注解一点用处都没有，而应该写在此处开发参数配置文件（****。dat）读出系统初始化参数。
在写注解的使用另外要注意的一个问题是分清楚系统自动生成的代码和用户自己开发的代码，一般来说没有必要写系统自动生成的代码。象delphi的代码，我们往往要自己编写一些自己的代码段，还要对一些系统自动生成的代码段进行修改，这些代码在阅读过程是要写注解的，但有一些没有修改过的自动生成的代码就没有必要写注解了。
在主要代码段要写较为详细的注解。有一些函数或类在程序中起关键的作用，那么要写比较详细的注解。这样对你理解代码有很大的帮助。5对你理解起来比较困难的地方要写详细的注解，在这些地方往往会有一些编程的技巧。不理解这些编程技巧对你以后的理解或移植会有问题1。
调整心态，反复阅读
和看晦涩难懂的树木一样，代码也需要反复阅读才能逐渐增加理解。我有个好心态，就是在遇到难懂的书目和代码时，我总是告诉自己不要着急，一边看不懂再来一遍，看个三五遍自然懂了，所谓“书读百遍，其意自现”嘛。其实远远不用5遍，大概三遍左右一般就能弄懂了，5遍的时候已经了熟于心了。项目源代码的代码量多没啥，但是我们自己心里不要着急，慢慢来，自己努力的功夫到了，多花点时间在看代码思考代码上，代码总会被你一点点感动的。如果遇到看不懂代码的情况，就分析下自己为什么看不懂？是项目使用了自己不熟悉的设计模式？还是一些业务领域基础知识自己没有掌握？或者是自己对项目框架的理解不对导致的，要自己主动的分析。
工欲善其事，必先利其器
用着顺手的IDE真的会为我们阅读代码节省很多时间。由于工作环境限制，刚开始时我在VS2003上面阅读项目代码，那体验额emmmm…无法更改IDE，我就找个辅助工具吧。后来找到了VAssistX，真的方便了很多，阅读效率和心情都得到了很大提升。据网友们推荐，source insight 看代码很不错，以后我也试试。同时，我们也可以用EA（Enterprise Architecture）逆向工程绘制工程的uml 类图，帮助我们理解项目中各类之间的调用关系。
揣摩作者的编程习惯与思想
除了工具及技巧之外，「想要阅读程序代码，得先试着阅读写这个程序代码的程序人的心。」这句话说来十分抽象，或许也令人难以理解。
当你在阅读一段程序代码时，或许可以试着转换自己的立场，从旁观者的角度转换成为写作者的心态，揣摩原作者的心理及处境。当你试着设身处地站在他的立场，透过他的思考方式来阅读、追踪他所写下的程序代码，将会感觉更加流畅。我在阅读非自己所写的程序代码时，会观察原作者写作的习惯，藉以对应到脑中所记忆的多种写作模型。在阅读的过程中，读完几行程序代码，我会试着猜想原作者在写下这段程序代码时的心境。他写下这段程序代码的用意是什么？为什么他会采取这样的写法？顺着原作者的思考理路阅读，自己的思考才能更贴近对方写作当时的想法。当你短暂化身为原作者时，才能更轻易的理解他所写下的程序代码。如果你能知道原作者的背景，程序设计时的偏好，阅读他的程序代码，就更能得心应手了2。
最后，推荐大家一本书，《代码阅读与实践》，可能大家看完会有更多收获。
————————————————
版权声明：本文为CSDN博主「祝枫」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Vince_ZHU/article/details/82903834