提高对不熟悉代码的理解的工具和技术？
我意识到作为一名编程学生，我最大的弱点是理解别人代码的能力很差。
我对“教科书”代码或带有明确注释的代码没有任何问题，但是当给定一个几百行的程序，包含十几个不同的函数并且没有注释时，我发现甚至很难开始。
我知道这种类型的代码是我在职业生涯中可能更容易遇到的，并且我认为糟糕的代码理解能力将对我来说是一个很大的障碍，所以我想专注于提高我的技能在这个区域。
根据您的经验，哪些工具/技术有助于提高代码理解能力？
您倾向于如何处理不熟悉的、未注释的代码？为什么？您认为您的技术有什么帮助？
谢谢
I've realised that my greatest weakness as a programming student is my poor ability to comprehend other people's code.
I have no trouble whatsoever with 'textbook' code, or clearly-commented code, but when given a program of a few hundred lines, containing a dozen or so different functions and no comments, I find it very difficult to even begin.
I know this type of code is what I'm probably more likely to encounter in my career, and I think that having poor code comprehension skills is going to be a great hindrance to me, so I'd like to focus on improving my skills in this area.
What tools/techniques have helped improve code comprehension in your experience?
How do you tend to tackle unfamiliar, uncommented code? Why? What about your technique do you find helpful?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
熟悉外国代码
如果代码库足够小，您可以立即开始阅读。到了某个时候，这些碎片就会开始拼凑在一起。
在这种情况下，“足够小”会有所不同，随着您的经验增加，它会变得更大。您还将开始从这里的“作弊”中受益：您可以跳过根据经验识别为“实现模式 X”的代码片段。
您可能会发现在阅读代码时绕一些小弯路很有帮助，例如，在看到函数被调用时查找该函数，然后花一点时间浏览一下它。在了解被调用函数的作用之前，不要走这些弯路；这不是重点，它会让你感觉自己在跳来跳去，毫无进展。绕道的目标是在不到半分钟的时间内了解新函数的作用。如果不能，说明该功能太复杂。中止绕道并接受这样一个事实：在没有这种额外帮助的情况下，您将必须了解您的“当前”功能。
如果代码库太大，你就无法开始阅读它。在这种情况下，您可以首先在高级抽象级别上识别程序的逻辑组件。您的目标是将源代码中的类型（类）与这些组件相关联，然后确定每个类在其组件中扮演的角色。组件中将有内部使用的类，以及用于与其他组件或框架进行通信的类。这里进行分而治之：首先将类分成相关的组，然后关注一个组并了解其各个部分如何组合在一起。
为了帮助您完成此任务，您可以使用源代码的结构作为指南（而不是作为最终法则；由于人为错误，它有时可能会产生误导）。您还可以使用函数或类型的“查找用法”等工具来查看每个函数或类型的引用位置。再次强调，如果您不能相当快地完成，请不要尝试完全理解 IDE 告诉您的内容。当这种情况发生时，这意味着您从一台您不太了解的机器中取出了一块复杂的金属。把它放回去并尝试其他的东西，直到找到你可以理解的东西。
调试外部代码
这完全是另一回事。我会稍微欺骗一下，除非你积累了大量的经验，否则只要代码对你来说是陌生的，你就不可能成功地调试它。
Familiarizing yourself with foreign code
If the codebase is small enough, you can start reading it straight away. At some point the pieces will start falling together.
In this scenario, "small enough" varies, it will get larger as your experience increases. You will also start benefiting from "cheating" here: you can skip over pieces of code that you recognize from experience as "implementing pattern X".
You may find it helpful to make small detours while reading the code, e.g. by looking up a function as you see it being called, then spend a little time glancing over it. Do not stay on these detours until you understand what the called function does; this is not the point, and it will make you feel like you are jumping around and making no progress. The goal when detouring is to understand what the new function does in less than half a minute. If you cannot, it means that the function is too complicated. Abort the detour and accept the fact that you will have to understand your "current" function without this extra help.
If the codebase is too large, you can't just start reading it. In this case, you can start by identifying the logical components of the program at a high level of abstraction. Your goal is to associate types (classes) in the source code with these components, and then identify the role each class plays in its component. There will be classes used internally in a component and classes used to communicate with other components or frameworks. Divide and conquer here: first split the classes into related groups, then focus on a group and understand how its pieces fit together.
To help you in this task, you can use the source code's structure as a guide (not as the ultimate law; it can be misleading at times due to human error). You can also use tools such as "find usages" of a function or type to see where each one is referenced. Again, do not try to fully digest what the IDE tells you if you can't do it reasonably quickly. When this happens, it means you picked a complicated piece of metal out of a machine you don't quite understand. Put it back and try something else until you find something that you can understand.
Debugging foreign code
This is another matter entirely. I will cheat a little by saying that, until you amass tons of experience, there is no way you will be debugging code successfully as long as it is foreign to you.
我发现绘制调用图和继承树通常对我有用。您可以使用任何手边的工具；我通常只使用白板。
通常，代码单元/函数本身很容易理解，而且我可以清楚地看到每个单元是如何运行的，但我经常无法看到更大的图景，这就是故障发生的地方，我得到这个“我”我迷失了”的感觉。
从小处开始。对自己说：“我想要完成x，那么在代码中是如何完成的呢？”其中 x 是您可以跟踪的一些小操作。然后，只需跟踪代码，制作一些可视化的东西，以便您可以在跟踪后回顾。
然后，选择另一个x并重复该过程。每次执行此操作时，您都应该对代码有更好的感觉。
当需要实现某些东西时，选择与您追踪的事物之一相似（但不几乎相同）的东西。通过这样做，您可以从跟踪级别的理解转变为实现级别的理解。
与第一次编写代码的人交谈也很有帮助。
I find that drawing the call-graph and inheritance trees out often works for me. You can use any tool you have handy; I usually just use a whiteboard.
Usually, the code units/functions are easy enough to understand on their own, and I can see plainly how each unit operates, but I often times have trouble seeing the bigger picture, and that's where the breakdown happens and I get this "I'm lost" feeling.
Start small. Say to yourself: "I want to accomplish x, so how is it done in the code?" where x is some small operation that you can trace. Then, just trace the code, making something visual that you can look back on after the trace.
Then, pick another x and repeat the process. You should get a better feel for the code every time you do this.
When it comes time to implement something, choose something that is similar (but not almost identical) to one of the things you traced. By doing this, you go from a trace-level understanding to an implementation-level understanding.
It also helps to talk to the person who wrote the code the first time.
我尝试做的第一件事是弄清楚代码的高层次目的是什么——在您对问题域有所了解之前，细节是无关紧要的。弄清楚这一点的好方法包括查看标识符的名称，但考虑上下文通常会更有帮助 - 您从哪里获得此代码？谁写的？它是某个具有已知用途的应用程序的一部分吗？一旦您弄清楚代码的用途，您就可以复制并开始重新格式化它，以便您个人更容易理解。这可以包括在必要时更改标识符的名称、整理任何奇怪的缩进、添加空格来分解事物、在弄清楚它们的作用后对位进行注释等等。无论如何，这是一个开始......:)
另外——一旦你弄清楚了代码的目的，通过调试器在一些简单的例子上逐步执行它有时也可以让你更清楚地了解FWIW发生了什么......
The first thing I try and do is figure out what the purpose of the code is at a high-level -- the detail's kind of irrelevant until you understand a bit about the problem domain. Good ways to figure that out include looking at the names of the identifiers, but it's usually even more helpful to consider the context -- where did you get this code? Who wrote it? Was it part of some application with a known purpose? Once you've figured out what the code's supposed to do, you can make a copy and start reformatting it to make it easier for you personally to understand. That can include changing the names of identifiers where necessary, sorting out any weird indentation, adding whitespace to break things up, commenting bits once you've figured out what they do, etc. That's a start, at any rate... :)
Also -- once you've figured out the purpose of the code, stepping it through a debugger on some simple examples can also sometimes give you a clearer idea of what's going on FWIW...
我理解您的沮丧，但请记住，那里有很多糟糕的代码，所以请保持乐观。并非所有代码都是坏的:)
这是我倾向于遵循的过程：
祝你好运
I understand your frustration, but keep in mind that there is a lot of bad code out there, so keep your chin-up. not all code is bad :)
this is the process that I tend to follow:
Good luck
Understand 是一个很棒的代码分析工具。它在我以前的雇主 (L-3) 中被广泛使用，所以我在我目前工作的地方购买了它。
Understand is a terrific code analysis tool. It was in wide use at my previous employer (L-3) so I purchased it where I currently work.