With a complex code base the biggest mistake you can make is trying to be a computer. Get the computer to run the code, and use a debugger to help find out what is going on.
Figure out how to compile, install and run your own version of Wine from the existing source code.
Learn how debug (e.g. use gdb) on a running instance of your version of Wine.
Run Wine under the debugger and make cause it to demonstrate the undesired behaviour.
The fun part: find where the code execution path goes and start learning how it all goes together.
Yes, reading lots and lots of code will help, but the compiler/debugger/computer can run code a lot faster than you.
A professor once told us to compare such a situation with climbing a mountain. You might be listening to someone who did this and tells you what it's like to look out into the country. And you believe without hesitation that that's a spectacular sight.
However, you have to start climbing yourself for real understanding what the view from the top is like.
And it's not that important to climb all the way to the top. It might be perfectly suficient just to reach a fair height above ground level.
But don't ever be afraid of start climbing. The view is always worth any efforts.
This has always been a nice analogy for me. I know this question was more about specific tips on how to efficiently deal with code bases once you started climbing. But nevertheless it instantly reminded me of our physics classes way back then.
(This is an answer I posted to a question a while back. I modified it a bit to fit this question.)
Experience has shown me that there are 3 major goals you have when learning a legacy system:
Learn what the code is supposed to do.
Learn how it does them.
(crucially) Learn why it does them the way it does.
All three of those parts are very important, and there's a few tricks to help you get started.
First, resist the temptation to just ctrl-click (or whatever your IDE uses) your way around the code to understand everything. You probably won't be able to keep everything in perspective in your mind this way, especially when each line forces you to look at multiple other classes in order to understand what it is, so you need to be able to hold several levels of the stack in your head.
Read documentation where possible; it usually helps you quickly gain a mental framework upon which to build everything that follows.
Run test cases where possible.
Don't be afraid to ask someone who knows if you have a question. Granted, you shouldn't waste others' time with inane queries, but if there's something that you simply don't understand (this is especially true with more conceptual questions like, "Wouldn't it make much more sense to implement this as a ___" or something), it's probably worth finding out the answer before you mess something up and don't know why.
When you do finally get down to reading the code, start at a logical "main" place and go from there. Don't just read the code top to bottom, or in alphabetical order, or anything (this is probably obvious).
The best way to get acquainted with a large codebase is to dive in. Many projects have a list of easy tasks that need to be done, and they're usually reserved to help ease people in. You should find and work on some of these; you'll learn a lot about the general code outline and structure, contribute to the project, and get an easy payoff that will help encourage you to take on larger tasks.
Like most projects, WINE has good resources available to its developers; IRC, wiki, mailing list, and guides/overviews. With most daunting codebases, it's not so scary after the first few fixes. WINE is truly large, and much like the kernel, I doubt there's any expert in all systems; don't feel like you need to be either. Start working on something that matters to you and take it from there.
I've started a few patches to WINE myself, and it's a good community and good structure. There's lots of very helpful debug messages, and it's a really cool project to work on, so that helps you hit it longer too.
We all appreciate your valor and willingness to help with WINE (it needs it). Thanks, and good luck.
Dig in. Think of a question you'd like to have answered, and try to find the answer. When you get tired of reading code, go read the dev mailing list, the developer's guide, or the wiki.
Unfortunately, there's no royal road to understanding a large code base. If you enjoy that sort of thing (I do) you're in for some fun. If not, guide books won't really help, so you aren't really that much worse off.
Look for one peculiar feature you are interested to improve. Search for its implementation. Once you found it, pull on that straw and all the rest will follow.
The best way is through comments.
I'm being ironic, as you understand tiny bits of the beast add comments so you can follow your trail.
The other developers will also enjoy it if you add the missing guides in the code.
Try to implement some tiny little change in the code, something that will be visible to you. That might be figuring out a workable way to output debugging statements (and figuring out where the output appears), it might be changing the default size of windows or desktop color, or something. Once you can make something happen in the codebase, you've scratched the surface of understanding and can begin to move on toward more complicated things. At that point, select a goal of something slightly more useful that you'd like the code to do, and implement that. Or check out the project's bug tracker and look for something small to start with.
Document as you go, and write unit tests as you go, and refactor as you go. When you figure out what a routine does, comment it!!
As others have suggested, dig in! Read all the available documentation you can absorb. Then see if you can find other people who are interested or knowledgeable and learn with/from them. It helps to have people to bounce ideas off of and ask questions.
For C source code, once you get a feel for what areas of the code you'd like to work on, generate ctags and cscope databases for that code. These tools make it a lot easier to jump around and understand the code. Many text editors (one example is gvim) have support for ctags and cscope so you can jump around easily.
A good way to understand a large system is to break it down into it's constituent parts and focus on a specific paths through the application.
Your debugger is your friend here, set a breakpoint in the thread you want to investigate then step through it line by line looking at which each part does... hope that helps...
发布评论
评论（11）
对于复杂的代码库，你可能犯的最大错误就是试图成为一台计算机。 让计算机运行代码，并使用调试器来帮助找出发生了什么。
了解如何从现有源代码编译、安装和运行您自己的 Wine 版本。
了解如何从现有源代码编译、安装
了解如何在您的 Wine 版本的运行实例上进行调试（例如使用 gdb）。
了解如何
在调试器下运行 Wine 并使其表现出不需要的行为。
有趣的部分：找到代码执行路径的走向，并开始学习它们是如何结合在一起的。
有趣的部分：
是的，阅读大量代码会有所帮助，但是编译器/调试器/计算机可以比您更快地运行代码。
With a complex code base the biggest mistake you can make is trying to be a computer. Get the computer to run the code, and use a debugger to help find out what is going on.
Figure out how to compile, install and run your own version of Wine from the existing source code.
Learn how debug (e.g. use gdb) on a running instance of your version of Wine.
Run Wine under the debugger and make cause it to demonstrate the undesired behaviour.
The fun part: find where the code execution path goes and start learning how it all goes together.
Yes, reading lots and lots of code will help, but the compiler/debugger/computer can run code a lot faster than you.
一位教授曾经告诉我们，把这种情况比作爬山。 您可能正在听这样做的人告诉您看看这个国家是什么感觉。 你会毫不犹豫地相信那是一个壮观的景象。
然而，您必须亲自开始攀爬，才能真正了解顶部的景色。
而且一路爬到顶峰也不是那么重要。 只要达到距地面相当的高度就足够了。
但永远不要害怕开始攀登。 看到风景总是值得付出任何努力。
这对我来说一直是一个很好的比喻。 我知道这个问题更多的是关于一旦开始攀登如何有效处理代码库的具体技巧。 但不管怎样，它立刻让我想起了那时我们的物理课。
A professor once told us to compare such a situation with climbing a mountain. You might be listening to someone who did this and tells you what it's like to look out into the country. And you believe without hesitation that that's a spectacular sight.
However, you have to start climbing yourself for real understanding what the view from the top is like.
And it's not that important to climb all the way to the top. It might be perfectly suficient just to reach a fair height above ground level.
But don't ever be afraid of start climbing. The view is always worth any efforts.
This has always been a nice analogy for me. I know this question was more about specific tips on how to efficiently deal with code bases once you started climbing. But nevertheless it instantly reminded me of our physics classes way back then.
（这是我不久前发布的一个问题的答案。我对其进行了一些修改以适应这个问题。）
经验告诉我，学习遗留系统时有 3 个主要目标：
所有这三个部分都非常重要，有一些技巧可以帮助您入门。
首先，抵制住通过按住 Ctrl 键单击（或您的 IDE 使用的任何内容）来理解代码的诱惑。 您可能无法以这种方式在头脑中清楚地了解所有内容，特别是当每行都迫使您查看多个其他类以了解它是什么时，因此您需要能够掌握多个级别的堆积在你的脑海里。
尽可能阅读文档； 它通常可以帮助你快速获得一个心理框架，在此基础上构建接下来的一切。
尽可能运行测试用例。
如果您有疑问，请不要害怕询问认识的人。 诚然，你不应该在愚蠢的查询上浪费别人的时间，但如果有一些东西你根本不理解（对于更概念性的问题尤其如此，比如“将其实现为一个___”或其他什么），在你把事情搞砸并且不知道为什么之前找出答案可能是值得的。
当您最终开始阅读代码时，从逻辑上的“主要”位置开始，然后从那里开始。 不要只是从上到下、或按字母顺序或任何其他方式阅读代码（这可能是显而易见的）。
(This is an answer I posted to a question a while back. I modified it a bit to fit this question.)
Experience has shown me that there are 3 major goals you have when learning a legacy system:
All three of those parts are very important, and there's a few tricks to help you get started.
First, resist the temptation to just ctrl-click (or whatever your IDE uses) your way around the code to understand everything. You probably won't be able to keep everything in perspective in your mind this way, especially when each line forces you to look at multiple other classes in order to understand what it is, so you need to be able to hold several levels of the stack in your head.
Read documentation where possible; it usually helps you quickly gain a mental framework upon which to build everything that follows.
Run test cases where possible.
Don't be afraid to ask someone who knows if you have a question. Granted, you shouldn't waste others' time with inane queries, but if there's something that you simply don't understand (this is especially true with more conceptual questions like, "Wouldn't it make much more sense to implement this as a ___" or something), it's probably worth finding out the answer before you mess something up and don't know why.
When you do finally get down to reading the code, start at a logical "main" place and go from there. Don't just read the code top to bottom, or in alphabetical order, or anything (this is probably obvious).
熟悉大型代码库的最佳方法是深入研究。许多项目都有一个需要完成的简单任务列表，它们通常是为了帮助人们轻松入门而保留的。您应该找到并处理其中的一些任务; 您将学到很多关于一般代码大纲和结构的知识，为项目做出贡献，并获得轻松的回报，这将有助于鼓励您承担更大的任务。
与大多数项目一样，WINE 为其开发人员提供了良好的资源； IRC、wiki、邮件列表和指南/概述。 对于大多数令人畏惧的代码库来说，经过最初的几次修复后，一切都不再那么可怕了。 WINE 确实很大，而且很像内核，我怀疑是否有任何专家精通所有系统； 我也不觉得你需要这样做。 开始做一些对你来说重要的事情，然后从那里开始。
我自己已经开始对 WINE 进行一些补丁，它是一个很好的社区和良好的结构。 有很多非常有用的调试消息，这是一个非常酷的项目，因此也可以帮助您更长时间地完成它。
我们都感谢您在 WINE 方面提供帮助的勇气和意愿（它需要它）。 谢谢，祝你好运。
The best way to get acquainted with a large codebase is to dive in. Many projects have a list of easy tasks that need to be done, and they're usually reserved to help ease people in. You should find and work on some of these; you'll learn a lot about the general code outline and structure, contribute to the project, and get an easy payoff that will help encourage you to take on larger tasks.
Like most projects, WINE has good resources available to its developers; IRC, wiki, mailing list, and guides/overviews. With most daunting codebases, it's not so scary after the first few fixes. WINE is truly large, and much like the kernel, I doubt there's any expert in all systems; don't feel like you need to be either. Start working on something that matters to you and take it from there.
I've started a few patches to WINE myself, and it's a good community and good structure. There's lots of very helpful debug messages, and it's a really cool project to work on, so that helps you hit it longer too.
We all appreciate your valor and willingness to help with WINE (it needs it). Thanks, and good luck.
深入思考。想一个你想要回答的问题，并尝试找到答案。 当您厌倦了阅读代码时，请阅读开发邮件列表，即开发人员指南，或wiki。
不幸的是，理解大型代码库没有捷径。 如果你喜欢这类事情（我也喜欢），那么你就会从中得到乐趣。 如果没有，指南书并没有真正的帮助，所以你的情况并没有那么糟糕。
Dig in. Think of a question you'd like to have answered, and try to find the answer. When you get tired of reading code, go read the dev mailing list, the developer's guide, or the wiki.
Unfortunately, there's no royal road to understanding a large code base. If you enjoy that sort of thing (I do) you're in for some fun. If not, guide books won't really help, so you aren't really that much worse off.
寻找您有兴趣改进的一项特殊功能。 搜索其实现。 一旦你找到了它，拉动那根吸管，剩下的一切就会随之而来。
Look for one peculiar feature you are interested to improve. Search for its implementation. Once you found it, pull on that straw and all the rest will follow.
最好的方法是通过评论。
我很讽刺，因为你了解这头野兽的微小部分，所以你可以添加评论，这样你就可以追踪你的踪迹。
如果您在代码中添加缺少的指南，其他开发人员也会喜欢它。
The best way is through comments.
I'm being ironic, as you understand tiny bits of the beast add comments so you can follow your trail.
The other developers will also enjoy it if you add the missing guides in the code.
尝试在代码中实现一些微小的更改，这些更改对您来说是可见的。 这可能是找出一种可行的方法来输出调试语句（并找出输出出现的位置），也可能是更改窗口的默认大小或桌面颜色等。 一旦您能够在代码库中让某些事情发生，您就已经触及了理解的表面，并且可以开始转向更复杂的事情。 此时，选择一个您希望代码执行的稍微有用的目标，然后实现它。 或者查看项目的错误跟踪器并寻找一些小问题来开始。
边做边记录，边写单元测试，边重构。 当你弄清楚例程的作用时，请评论它！
Try to implement some tiny little change in the code, something that will be visible to you. That might be figuring out a workable way to output debugging statements (and figuring out where the output appears), it might be changing the default size of windows or desktop color, or something. Once you can make something happen in the codebase, you've scratched the surface of understanding and can begin to move on toward more complicated things. At that point, select a goal of something slightly more useful that you'd like the code to do, and implement that. Or check out the project's bug tracker and look for something small to start with.
Document as you go, and write unit tests as you go, and refactor as you go. When you figure out what a routine does, comment it!!
正如其他人所建议的，深入挖掘！ 阅读您可以吸收的所有可用文档。 然后看看你是否可以找到其他感兴趣或知识渊博的人并与他们一起学习/向他们学习。 让人们互相交流想法并提出问题是有帮助的。
对于 C 源代码，一旦您了解了您想要处理的代码区域，就生成 ctags< /a> 和该代码的 cscope 数据库。 这些工具使跳转和理解代码变得更加容易。 许多文本编辑器（例如 gvim）都支持 ctags 和 cscope，因此您可以轻松跳转。
As others have suggested, dig in! Read all the available documentation you can absorb. Then see if you can find other people who are interested or knowledgeable and learn with/from them. It helps to have people to bounce ideas off of and ask questions.
For C source code, once you get a feel for what areas of the code you'd like to work on, generate ctags and cscope databases for that code. These tools make it a lot easier to jump around and understand the code. Many text editors (one example is gvim) have support for ctags and cscope so you can jump around easily.
（警告：无耻的营销）
对于使用 Eclipse 的 Java 开发人员来说，有 nWire。 它是一个 Eclipse 插件，用于导航和可视化大型代码库。
(warning: shameless marketing ahead)
For Java developers using Eclipse, there's nWire. It is an Eclipse plugin for navigating and visualizing large codebases.
理解大型系统的一个好方法是将其分解为各个组成部分，并重点关注应用程序中的特定路径。
您的调试器是您的朋友，在您想要调查的线程中设置一个断点，然后逐行查看每个部分的功能...希望有帮助...
A good way to understand a large system is to break it down into it's constituent parts and focus on a specific paths through the application.
Your debugger is your friend here, set a breakpoint in the thread you want to investigate then step through it line by line looking at which each part does... hope that helps...