我正在寻找一些好的技巧来跟踪和理解庞大的代码库。我通常从顶部开始，一段时间后就会迷失在函数的一些细节中。由于我已经深入很多级别，因此备份和走上正轨的过程既累人又累人。当你试图理解庞大的代码库时，你如何跟踪线索？
我通常会打开记事本并尝试跟踪步骤。但是在理解代码和做笔记之间切换对我来说并不是很有效。有什么建议吗？
编辑：我正在寻找一种我想修复错误的情况。我怀疑如果我将我的理解限制在存在错误的函数/类上，我将不会对我的修复充满信心。
【问题讨论】：
标签： language-agnostic legacy-code
首先回答问题：你想做什么？
可能的问题
您要评估设计/架构吗？
您要修复错误吗？
实现新功能？
可能的方法：
掌握一些静态分析工具：Sonar、Structure 101 就是示例。使用这些来获得架构的概述。
从测试错误开始（最好是 UnitTest，但调试器中的会话可以）。开始关注调试器。不要深入。检查变量的值是否存在意外值。
查找相关功能，按名称搜索并查看它们是如何实现的。忽略所有与手头任务无关的细节。
----针对问题版本的补充----
在您不知道的代码库中进行错误修复（并且可能没有广泛的自动测试）始终是一项有风险的业务。
我仍然认为上面介绍的一般方法是可取的。当然，它应该受到测试的“保护”：
进行更改。这应该会使之前的测试变为绿色
运行手动测试以确保应用程序按预期工作。
与往常一样，测试量取决于遗漏错误所带来的风险。
【讨论】：
关于代码考古学有一个有趣的SE Radio interview with "Pragmatic" Dave Thomas，就是关于这个话题。
一些想法，一些来自那次谈话，一些不是：
您有权访问 VC 存储库吗？发生大量变化的热点是什么？这为您提供了有关大量开发时间花费在何处的提示。
什么是最大的文件。不幸的是，代码往往会在使用它的地方累积，并且无需工作即可将其再次拆分，它会保留在那里。最大的文件通常也是最重要的文件。
有错误跟踪器吗？哪些组件的 bug 最多，这也可以告诉您问题发生在哪里（以及由于该逻辑很重要，可能集中在哪里开发。）
一个好的 IDE 可以让跟踪变得更容易，因为您可以跳转到定义并再次返回。
文档生成器，即使它没有任何 cmets，通常也可以对类或函数调用进行良好的图形表示，从而将您引导到正确的位置。
【讨论】：
有一种非线性（有点骇人听闻、横冲直撞、公认不专业）的方式来做到这一点 - 一种遵循面包屑的方法：
选择任意一行代码并继续阅读 直到你找到一些（比如说）功能或 吸引你注意力的课程；
复制其名称并用注释标记该块（“找到：[事物名称]”，逐步添加您关注的每个事物）；
然后搜索每个实例 这个词贯穿整个代码；
您会在 方式，所以记下所在的行 它的出现，以及它的作用。
在您完成此操作一段时间后（如果该方法对您有效），代码背后的想法就会变得明显，您有望很快找到所有主要连接。
在最坏的情况下，我还搜索并将所有名称不佳的变量、子例程等实例替换为更具描述性的内容（然后再次运行代码）。
当然（就像 Paul 所说）如果您使用可以列出已定义内容的编辑器或 IDE，那么您已经成功了一半 :-)
【讨论】：
通常我尝试做的事情是避免尝试从头开始理解代码。我通常会查看代码中的所有类和包，看看哪些是我可能有兴趣进一步研究的突出内容。专注于了解这一小块是如何独立工作的。
然后我会继续编写另一段代码，等等，希望在足够的时间后，我能理解所有代码段的工作原理，从而更容易理解全局。
【讨论】：
我从代码中的概念/逻辑开始。采用一个基本概念/逻辑并遵循它并了解开发人员是如何尝试这样做的。在这个过程中，我总是会找到相关的细节，然后再研究这些参数。
一旦您了解了代码的基本模型并了解了开发人员的想法，您就可以从那里获取它。一直为我工作:)
编辑：如果代码非常大。更高级别的建模会有所帮助。将代码划分为模块并了解它们如何相互连接。稍后逐个深入研究模块并按照我上面提到的技巧进行操作。
【讨论】：
我怀疑，如果我将我的理解限制在存在错误的函数/类上，我将不会对我的修复充满信心。
修复错误，如果您的修复破坏了其他内容或不足以修复它，请责怪代码作者没有编写可维护的代码。
您不必了解所有内容即可修复一件。
【讨论】：