拥有 C/C++ 基础的学生，如何看懂1万行代码的项目

本文所述的思想大都是网上各大家总结出来，仅供参考，我觉得这因人而异，如果作为一手来说，不妨借鉴以下方法：

看法一：

作者：网事如风

链接：http://www.zhihu.com/question/23503544/answer/24852187

来源：知乎

1.先搞明白这个项目做什么用的，都有哪些功能。可能有的人觉得这是废话，不过有的是人这个项目能做啥都不知道就开始看代码….此处可以留下一些疑问，比如想知道某些功能是怎么实现的。

2.仔细看文档，了解项目结构，此处可能解决一些步骤1留下的疑问，比如说某个功能用到了哪种技术，但应该增加更多的疑问，这些疑问一般就是具体实现了。当然这得看文档写的怎么样了。

3.把项目编译通过，找一个好的IDE，比如VS，方便看代码，更重要的是方便调试和改代码，如果项目本身没有你想用的IDE的工程，试着自己把它改成自己常用的IDE可以编译的项目。如果项目太大，这个一般不太现实，不过一两万行的代码应该还是可以的。

4.看代码。边看边注释，可以从main函数开始看，如果在看文档和编译的时候就对某部分非常感兴趣的话，可以不用从main开始，直接看感兴趣的部分。如果对某段代码理解不透，可以在这里下断点，调试运行项目，看什么更能会触发这个断点，然后通过调用堆栈看从什么地方调用的或者跟进相关的函数看看他做了什么，也可以试着把它注释掉并且让项目可以编译通过，然后运行看看他对程序的影响。好的IDE的查找引用的功能可以帮你快速的了解某个函数或者类在什么地方用到了，方便你更好地理解它。这也是为啥要用一个好的IDE。

5.自己动手改这个项目。这一步要看有没有必要做得这么深入了。纸上得来终觉浅，不把这个项目改的面目全非，你是不可能完全理解这个项目的；不能把这个项目改的符合自己的要求，也就没啥必要去看他了。

另外在此期间你会遇到各种稀奇古怪的问题，这时候就需要靠搜索引擎或者其他方法去解决

看法二：

1. 编译运行通过

2. 从main入口开始了解整个程序框架

3. 尝试修改、增减功能

4. 闭上眼，仔细回想整个项目

作者：蓝色

链接：http://www.zhihu.com/question/23503544/answer/24777267

来源：知乎

针对很多人所述说的文档，领域知识之类，而且还说什么这是没有什么工作经验的说法，我也表示直接反对，所以更新信息。

第一：无论你领域知识、文档看的多顺，你不能编译运行起来，那我们什么都别说了，这是第一步骤，也是最重要的一步，而且也是切身经验之谈。在我参与的C++编译器项目中，是有很多文档给我，而且编译原理的书籍也多如牛毛，但是我加入开发的时候，我自己完全无法编译运行我们小组的C++编译器（不要认为就是什么点一个按钮，或者敲一行命令就行了），因为涉及到的权限与配置环境的复杂度都很多。OK，那我文档与编译原理看的再顺，有个P用。理解了一大堆词法分析、语法分析、什么First集合和Follow集合，弄的滚瓜烂熟，你编译运行不通过，看不到效果，有什么用？

第二：有些项目的文档完全跟不上代码（更别说很多题主所述的项目，还有可能没有文档），那么这个时候，你最能依靠的只有代码。在我离职IBM的时候，Leader曾经向我询问过如今编译器存在的问题与建议，我曾经有过一条反馈就是文档跟不上代码，很多过于陈旧。而Leader也说的很直接，文档很重要，我们也知道，而且编译器组还有专门的文档团队，但是那只能是写给外面使用者的，编译器内部的文档只能工程师写。但是编译器每天都交很多代码，还跨国跨地区，谁能总结得了？这时候的武器依然只能是代码。而团队的Mentor当初也很直白的说，你只能是找到程序的入口，然后跟进去，然后逐步摸清楚门路（IBM编译器项目已经有几十年的历史，你可以想象这个规模有多么的庞大，即使庞大如斯，也只能这样做）。也许你有看不懂的地方，没有关系，看不懂的地方找你的Leader（老师），然后如果这是缺乏的领域知识，那你就去自行补足。

你能依靠的就是代码，以代码驱动你去学习与补足知识。我还是那句，你不能运行起来项目，什么都别说了，说那么多有个P用。

看法三：

作者：长生

链接：http://www.zhihu.com/question/23503544/answer/24830632

来源：知乎

一般来说，新接触的项目第一步应是快速深入了解整个项目。快速而深入了解一个项目的第一选择永远是阅读项目文档。一上来就看代码无异于盲人摸象。

你首先应从项目文档里面对整个项目有一个整体的认识，包括：

1.项目的目的

2.项目的环境

3.项目的功能模块划分

4.各功能模块的业务流程（或运行结果）

了解了以上信息之后，再去对应着各功能模块去看代码。

对于一般项目来说，代码上基本没有难度，算法研究类的另当别论。

看法四：

作者：远的树洞

链接：http://www.zhihu.com/question/23503544/answer/25418479

来源：知乎

这是一个迭代的过程。我觉得文档和代码都重要 一起看才能理解的最快，前提是有充足的文档，如果没有就另说咯。不过很多细节代码是最直接的，代码不会欺骗你，对就对，错就错，再复杂的算法，逻辑，都要在代码体现，所以在文档和代码迭代不同步的项目上，代码才是唯一可信的。不同步的文档有时候还要误导程序员。

以我现在的项目为例子，科学计算的项目，整个项目6W＋行C／C＋＋代码。因为涉及算法比较多所以文档很重要，理解数学公式要花60％的时间，代码实现只需40％时间，所以这种项目的功能模块理解很依赖文档。没文档和公式基本看不懂。但如果要理解整个项目就不需要理解每个功能模块的细节，只需要分析清模块输入输出输出就OK了。主要看懂程序的流程，其实就是数据的输入输出。

我比较认同第一个答案，那些说从main开始看下去是菜鸟的，我表示强烈反对，难道不从顶层看起，还从底层看起，你从底层看懂了，也只懂一个功能而已，程序的主体流程，业务，你是一点也没懂的，根本就谈不上理解这个项目。

最后还是觉得看项目，还是个迭代的过程，多自己动手看，修改修改，编译输出，以实际检验自己的猜测。说不定还能检查出BUG呢。

看法五

作者：一羞合上

链接：http://www.zhihu.com/question/23503544/answer/24986774

来源：知乎

读代码这事儿吧，我以为，该自顶向下的读。先看文档，从需求分析到设计，与明白人沟通，搞明白这东西是做什么的，业务流程怎么来怎么去，有哪些场景，有哪些状态，各种状态间以什么触发变化等等等等。就是说，要把“读代码”这个动作尽量的往后放。在正式“读代码”之前，尽可能的做到“除了代码没看过，别的都看过了差不多也都明白了”。最后就是读代码了。

怎么读呢？在读代码之前，已经摸清了大部分场景了，就以场景为单位，带入做白盒测试，代码走读。尽量不要纠结于某些细节，能够从比较高的抽象层次大概了解流程、结构最好。让“了解细节”这个动作尽量的靠后，最好是在“了解细节”这个动作发生时，已经大致了解了整个程序的结构以及主要功能模块。最后嘛，是否要“了解细节”视情况而定。如果老大要你动某块代码，再深入了解也来得及。

说了这么多，实际上就是一个原则，在任何时候，都要控制自己正在处理的信息的复杂度，尽可能的降低复杂度。以面向对象的思想来讲，就是控制抽象的边界。边界范围过大，会导致大脑同时处理的信息过多，复杂度偏高会超出大脑的处理能力。大脑擅长做的工作不是处理大量的细节，而是分而治之。

比较基础的方法

1.运行编译成功

2.项目文档如果有，一定要看，特别是ReadMe文档，里面一般有各个模块的解析，如果熟悉了就清楚了

3.找到入口函数，单步调试，一步步单步调试，弄清每一步的意图

仁者见仁，智者见智，如果自己有看法可以在下面评论，大家一起学习