如何快速理解任何产品的设计和代码流程？ [关闭]

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

人们确实会慢慢地、稳定地理解代码，但是接近代码库的最佳和明智的方式应该是什么，以便他快速理解代码并开始交付？

Note:我尝试了 Star UML，并尝试对类图进行逆向工程，以便我对产品内部设计有一个粗略的了解，但惨败。

EDIT:问题不在于了解产品的功能，而在于内部结构是如何设计的。

使用断点修复错误和调试确实提供了一种实现此目的的方法，但我正在寻找是否有更快的方法可以实现此目的

用基思的话来说：

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

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

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

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

当我这样做的时候，我正在构建一个我将如何实现它的心理模型。令人惊讶的是，这种以用户为导向的产品第一次接触通常会让我对应用程序的理解远远超过长期致力于该应用程序的开发人员。这种方法的一个副作用是，我倾向于发现相当多的错误（通常是大量的错误），并想到了相当多的改进，这些改进should被制作。

之后，我查看程序的总体结构，无论是模块、类、文件还是模式。Not查看各个代码行，除了那些显示程序架构的代码行。一旦我认为我理解了一半以上的结构，我就会尝试进行一个小错误修复或改进——这需要几分钟的时间来编写，但可能需要几个小时才能正确理解。如果它有效，我会在某处进行稍大的更改，最好是在代码的另一部分。

通过这种方式，我发现每天可以很好地理解大约 50,000 到 100,000 行代码。