C++ 如何快速理解任何产品的设计和代码流？

我已经转投了一家新公司，我正在开发一种产品，它拥有庞大的代码库，没有文档。我想尽快熟悉产品的设计和代码流程，以便尽快成为一名高效的成员

慢慢地、稳步地理解代码，但是，为了快速理解代码并开始交付，接近代码库的最佳和明智的方式应该是什么

注意：我尝试使用Star UML，并尝试对类图进行反向工程，以便大致了解产品内部设计，但失败惨重

编辑：问题不在于了解产品的功能，而在于如何设计内部结构

修复bug和使用断点调试确实提供了一种实现这一点的方法，但我正在寻找是否有更快的方法来实现这一点

用基思的话说：

---

这可能适用于某些代码库，但总的来说，我认为这是个坏主意。您往往过于关注细节，而一开始您希望了解全局：类是什么，通信模式是什么，等等。另外，如果您有一个分布式应用程序（客户机-服务器、n层等），或者代码运行时间较长，那么通过调试器运行它可能不太实际

---

如果您有一个开发环境来运行代码，那么我发现最好的方法就是使用调试器，并在执行时观察代码流。您可以设置断点并逐步查看代码的交互方式

向你能找到的每一个人寻求帮助，并让他们向他们认为有帮助的任何人寻求帮助。

除了阅读代码/数据模型之外，我一直学习的方法是开始修复一些bug。这让我接触到了系统的各个部分，在阅读代码时有了“目的”使它更有意义。

有一些工具可以吸收源代码并绘制图片。试试Sparx的企业架构师。每个座位不到200美元，可以非常有效地显示对象布局。

我是一名合同工程师，在过去几十年中，这种情况每年都会发生好几次

我发现在查看任何代码之前，先运行应用程序并使用它是非常有帮助的：

• 它到底有什么用？如有必要，请阅读用户文档
• 极值会发生什么
• 如果我遗漏了一些值呢
• 如果我快速单击控件会发生什么
• 有没有办法滥用这个程序
• 探索应用程序的边缘：是否有很少使用或难以找到的子菜单？是否有公开更多功能的配置工具

当我这么做的时候，我正在构建一个我将如何实现它的心智模型。令人惊讶的是，这种面向用户的产品第一次接触通常会导致我对应用程序的理解远远超过长期从事该应用程序开发的开发人员。这种方法的一个副作用是，我倾向于发现相当多的bug（通常是相当多的bug），并考虑应该进行的相当多的改进

之后，我将查看程序的一般结构，无论是模块、类、文件还是模式。不查看单独的代码行，除了那些显示程序架构的代码行。一旦我认为我理解了一半以上的结构，我就会尝试进行一个小的bug修复或改进，这需要几分钟来编写，但可能需要几个小时才能正确理解。如果可行，我会在某个地方做一个稍微大一点的更改，最好是在代码的另一部分

---

这样,，我发现每天可以理解大约50000到100000行代码。

根据公司的设置，如果您有任何QA资源在应用程序上进行测试，您可以要求他们提供一些常见的用例和测试信息，这样您就有了在调试时运行程序的基础。+1在学习一个新系统时，我尝试做的第一件事是在调试器中逐行检查它。这可能对一些代码库有效，但总的来说，我认为这是一个坏主意。您往往过于关注细节，而一开始您希望了解全局：类是什么，通信模式是什么，等等。另外，如果您有一个分布式应用程序（客户机-服务器、n层等），或者需要很长时间运行的代码，通过调试器运行可能不太实际。+1单步执行代码并记下电子表格中的重要函数会有所帮助。我通常会把所有的电话都组织在一张电子表格中，并试图获得一个更大的图景。为什么会有更多的选票？OP说他有一个“巨大的”代码库；你可能会经历几年，但实际上什么也学不到。你如何决定首先看哪一部分？我不知道你所说的“更快的学习方法”是什么意思。不看实际的代码，你还应该如何知道它是如何工作的？+1实际上，使用代码是学习它的好方法。这里没有魔法药丸，请不要这样做。与那些坚持被填鸭式地灌输所有信息的人一起工作不仅非常令人沮丧，而且会降低工作效率。在使用这种方法之前一定要努力，你的队友会感谢你的。；）寻求帮助是最快的，有时也是了解发生了什么的唯一途径，特别是对于复杂系统。没有文档是有原因的——他们没有时间创建文档。关于代码的知识存在于头脑中，或者根本不存在。他需要了解他希望填补的知识空白是什么，这是通过询问队友来实现的。我认为这是目前为止最好的方法。@wallyk谢谢这是一个很好的回答