了解巨大的整体代码的提示

Question

我正在寻找一些跟踪和理解庞大代码库的好技巧。我通常从顶部开始，并在一段时间后最终迷失在函数的一些细节之中。由于我已经处于很多层次，因此备份和进入轨道的过程令人厌倦和疲惫不堪。当您尝试理解庞大的代码库时，如何跟踪路径？

我通常打开记事本并尝试跟踪步骤。但是在理解代码和记笔记之间切换对我来说并不是真正有效。有什么提示吗？

编辑：我正在寻找一个我想修复bug的情况。我怀疑如果我将我的理解限制在存在错误的函数/类中，我将不会对我的修复有信心。

Answer 1

首先回答这个问题：你想做什么？

可能的问题

1. 您想评估设计/架构吗？

2. 您想修复错误吗？

3. 实施新功能？

可能的方法：

1. 掌握一些静态分析工具：Sonar，Structure 101就是例子。使用它们来概述架构。

2. 从错误的测试开始（理想情况是UnitTest，但调试器中的会话会这样做）。开始关注调试器。不要深入。检查变量的值是否有意外值。

3. 查找相关功能，按名称搜索这些功能并查看其实现方式。忽略与手头任务无关的所有细节。

----另外回应问题的版本----

在您不知道的代码库中执行错误修复（以及可能没有大量自动测试的代码库）始终是一项有风险的业务。

我仍然认为上面提出的一般方法是可取的。当然它应该通过测试“保护”：

• 一旦确定了必须进行更改的区域，请检查谁在使用此代码以及以何种方式使用此代码。小心地添加日志并运行应用程序可能会有所帮助。
• 编写测试以记录当前行为（那些应该是绿色并保持原样）
• 编写测试，记录更改后的更改行为（以红色开始）

• 进行更改。这应该使之前的测试成为绿色

• 运行手动测试以确保应用程序按预期工作。

与往常一样，测试的数量取决于错过错误所带来的风险。

Answer 2

关于代码考古学有一个有趣的SE Radio interview with "Pragmatic" Dave Thomas，关于这个主题。

一些想法，一些来自谈话，一些不是：

您是否可以访问VC回购？发生大量变化的热点是什么？这为您提供了大量开发时间花费的提示。

最大的文件是什么？不幸的是，代码往往会积累在使用它的地方，而没有工作将它再次拆分，它就会停留在那里。最大的文件通常也是最重要的文件。

是否有错误跟踪器？什么组件有最多的错误，这也告诉你哪里出现问题（可能由于逻辑重要而可能集中开发。）

良好的IDE使跟踪变得更加容易，因为您可以跳转到定义并再次返回。

文档生成器，即使没有任何注释，通常也可以对类或函数调用进行良好的图形表示，从而将您引导到正确的位置。

Answer 3

有一种非线性（某种黑客，横向和公认的不专业）的方式来实现这一点 - 一种遵循面包屑的方法：

• 选择任意代码行并继续阅读 直到找到一些（比如说）功能或 引起你注意的课程;

• 复制其名称并用注释标记该块（'找到：[物品名称]'，逐步添加您关注的每件事物）;

• 然后搜索每个实例 整个代码中的这个词;

• 你会在上面找到真正的“东西” 方式，所以记下行在哪里 它出现了，它做了什么。

在你完成这段时间之后（如果方法适合你），代码背后的思维变得明显，你希望能够很快找到所有主要连接。

在最糟糕的情况下，我也搜索过＆amp;将所有名称不佳的变量，子程序等实例替换为更具描述性的东西（然后再次运行代码）。

当然（如保罗所说）如果你使用一个可以列出定义内容的编辑器或IDE，你已经在那里了： - ）

Answer 4

通常我尝试做的是避免尝试从头到尾理解代码。我通常会查看代码中的所有类和包，看看哪些是我可能有兴趣进一步研究的东西。专注于了解这件小作品本身是如何运作的。

然后我转到另一段代码等等，希望在经过足够的时间之后，我会理解所有部分的工作方式，这使得理解大局变得更加容易。

Answer 5

我从代码中的概念/逻辑开始。采取一个基本的概念/逻辑，并遵循它，并实现开发人员如何尝试这样做。在这个过程中，我总能找到相关的细节，然后再研究这些参数。

一旦你拥有代码的基本模型以及开发人员如何思考它的一些想法，你就可以从那里开始。一直为我工作:)）

编辑：如果代码的大小非常大。更高层次的建模有帮助。将模块中的代码分开，并了解它们之间的连接方式。稍后单独潜入模块并遵循我上面提到的技巧。

Answer 6

我怀疑如果我将我的理解限制在存在错误的函数/类中，我将不会对我的修复有信心。

修复该错误，如果您的修补程序破坏了其他内容或者不足以修复它，请责怪代码作者不编写可维护代码。

你不应该理解一件事来解决一件事。