理解庞大的整体代码的技巧
我正在寻找一些好的技巧来跟踪和理解庞大的代码库。我通常从顶部开始，一段时间后最终会迷失在函数的一些细节中。由于我已经深入了很多层，所以倒车和走上正轨的过程是令人厌烦和疲惫的。当您试图理解庞大的代码库时，如何跟踪线索？
我通常会打开记事本并尝试跟踪步骤。但在理解代码和做笔记之间切换对我来说并不是很有效。有什么建议吗？
编辑：我正在考虑一个我想修复错误的情况。我怀疑如果我将我的理解限制在存在错误的函数/类上，我将不会对我的修复充满信心。
I am looking for some good tips to track and understand huge codebase. I usually start at the top and end up getting lost in some nitty-gritty details of a function after a while. Since I would have already been many levels deep, the process of backing up and getting on track is tiresome and exhausting. How do you keep track of the trail when you are trying to understand huge codebase?
I usually have a notepad open and try to track the steps. But switching between understanding the code and taking a notes is not really effective for me. Any tips?
EDIT: I am looking at a situation where I want to fix a bug. I am skeptical that if I limit my understanding to the function/class where the bug is present, I will not be confident about my fix.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
首先回答一个问题：你想做什么？
可能的问题
您想评估设计/架构吗？
您想修复错误吗？
实施新功能？
可能的方法：
掌握一些静态分析工具：例如声纳、Structure 101。使用它们来获得架构的概述。
从错误测试开始（最好是单元测试，但调试器中的会话也可以）。开始跟踪调试器。别往深处走。检查变量值是否有意外值。
查找相关功能，按名称搜索这些功能并查看它们是如何实现的。忽略与手头任务无关的所有细节。
---- 补充问题的版本 ----
在你不知道的代码库中进行错误修复（并且可能没有广泛的自动测试）始终是一项有风险的事情。
我仍然认为上面提出的一般方法是可取的。当然，它应该受到测试的“保护”：
进行更改。这应该使之前的测试变为绿色
运行手动测试以确保应用程序按预期工作。
像往常一样，测试的数量取决于错过错误所带来的风险。
First answer the question: What do you want to do?
Possible questions
Do you want to evaluate the Design/Architecture?
Do you want to fix a bug?
Implement a new feature?
Possible approaches:
Get hold on some static analysis tools: Sonar, Structure 101 are examples. Use those to get an overview of the architecture.
Start with a test of the bug (idealy a UnitTest, but a session in the debugger will do). Start following the debugger. Don't go to deep. Check the values of variables for unexpected values.
Look for related feature, search for those by name and see how they are implemented. Ignore all the details that don't relate to the task at hand.
---- addition in response to the edition of the question ----
Doing a bug fix in a code base you don't know (and which probably doesn't have extensive automatic tests) is always a risky business.
Still I think the general approach presented above is advisable. Of course it should be 'protected' by tests:
make your change. This should make the previous tests green
run manual tests to make sure the application works as intended.
As usual the amount of testing depends on the risk that comes with missing a bug.
有一个有趣的 SE 电台采访“务实”Dave Thomas关于代码考古学，关于这个话题。
有些想法，有些来自那次演讲，有些则不是：
你可以访问 VC 存储库吗？哪些热点发生了较大变化？这可以让您了解大量开发时间花在哪里。
最大的文件是什么。不幸的是，代码往往会在使用它的地方积累，并且如果不进行工作将其再次拆分，它就会留在那里。最大的文件通常也是最重要的文件。
有错误跟踪器吗？哪些组件有最多的错误，这也可以告诉您问题发生在哪里（并且可能由于逻辑很重要而开发集中在哪里）。
一个好的 IDE 使跟踪变得更加容易，因为您可以跳转到定义并再次返回。
文档生成器，即使没有任何注释，通常也可以对类或函数调用进行良好的图形表示，引导您到达正确的位置。
There is an interesting SE Radio interview with "Pragmatic" Dave Thomas about code Archeology, about just this topic.
Some ideas, some from that talk, some not:
Do you have access the VC repo? What are the hot spots where lots of changes occurred? This gives you a hint about where lots of development time was spent.
What is the biggest file. Unfortunately code tends to accumulate where it's used and without work to split it up again it stays there. The biggest file is often the most important one too.
Is there a bug tracker? What components have the most bugs, this also tells you where problems occur (and probably where development has been concentrated due to that logic being important.)
A good IDE makes tracking a lot easier as you can jump to definitions and back again.
A documentation generator, even if it there aren't any comments, can often make good graphical representations of classes or function calls that guides you to the right place.
有一种非线性（有点黑客行为、横向且不可否认的不专业）方法可以做到这一点 - 一种遵循面包屑方法：
选择任何代码行并继续阅读
直到你找到一些（比如说）功能或
吸引您注意力的类；
复制其名称并用注释标记该块（'found：[事物名称]'，逐步添加您关注的每个事物）；
然后搜索每个实例
这个词贯穿整个代码；
你会在上面找到真正的“东西”
方式，所以记下该行
它会出现，以及它会做什么。
完成此操作一段时间后（如果该方法适合您），代码背后的想法就会变得显而易见，您将有望很快找到所有主要连接。
在最坏的情况下，我也搜索过&将所有命名不当的变量、子例程等实例替换为更具描述性的内容（然后再次运行代码）。
当然（就像 Paul 所说）如果您使用可以列出已定义内容的编辑器或 IDE，那么您已经成功了一半:-)
There's a non-linear (sort of hackerish, sideways and admittedly unprofessional) way to do this - a kind-of follow the breadcrumbs approach:
choose any line of code and read on
until you find some (say) function or
class that grabs your attention;
copy its name and mark the block with a comment ('found: [name of thing]', incrementally adding each thing you follow);
then search for every instance of
this word throughout the code;
you'll find the actual 'thing' on the
way, so make a note of the line where
it appears, and what it does.
After you've done this awhile (if the method works for you) the thinking behind the code becomes apparent and you'll hopefully locate all the main connections quite quickly.
In the worst cases, I've also searched & replaced all instances of poorly-named vars, subroutines, etc. to something that makes more descriptive sense (then run the code again).
Of course (like Paul says) if you use an editor or IDE that can list defined stuff, you're already halfway there :-)
通常我尝试做的事情是避免尝试从头到尾地理解代码。我通常会查看代码中的所有类和包，看看哪些是我可能有兴趣进一步研究的。专注于理解这个小部件本身是如何工作的。
然后我继续编写另一段代码，等等，希望在足够的时间之后，我能够理解所有代码是如何工作的，这使得理解大局变得更容易。
Usually something I try to do is to avoid trying to understand the code from the top up. I usually look around all the classes and packages in the code and see which ones stand out as something I might be interested in looking at further. Focus on understanding how that small piece works by itself.
I then move on to another piece of code, etc, and hopefully, after enough time, I enderstand how all the pieces work which makes understanding the big picture much easier.
我从代码中的概念/逻辑开始。采用一个基本概念/逻辑并遵循它并实现开发人员如何尝试做到这一点。在这个过程中，我总是找到相关的细节，然后研究这些参数。
一旦您掌握了代码的基本模型并了解了开发人员的想法，您就可以从那里开始使用。总是为我工作:)
编辑：此外，如果代码的大小非常大。更高层次的建模会有所帮助。将代码划分为模块并了解它们如何相互连接。随后分别深入研究各个模块并遵循我上面提到的技巧。
I start with concepts/logics in the code. Take one fundamental concept/logic and follow it throw and realize how the developer tried to do it. In the process I always find associated details and then later study on those parameters.
Once you have basic model of the code and some idea of how the developer thought about it, you can take it from there. Always worked for me :)
EDIT: Also if code is very large in size. Modeling at higher level helps. Divide the code in modules and understand how they are connected to each other. Later dive into the modules individually and follow the trick I mentioned above.
我怀疑如果我将理解限制在存在错误的函数/类上，我对我的修复不会有信心。
修复该错误，并且如果您的修复破坏了其他内容或没有不足以修复它，责怪代码作者没有编写可维护的代码。
你不必了解所有事情才能修复一件事情。
I am skeptical that if I limit my understanding to the function/class where the bug is present, I will not be confident about my fix.
fix the bug, and if your fix breaks something else or isn't enough to fix it, blame the code author for not writing maintainable code.
you shouldn't have to understand everything to fix one piece.