blocks|key|299156|text|如果你有一个开发环境来运行代码，我发现的最好的方式是使用调试器，并在执行它的同时观察代码流。您可以设置断点并逐步执行该断点，以查看代码如何交互。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|299157|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you have a development environment to run the code in the best way I've found is to use a debugger and watch the flow of code while executing it. You can setup break points and step through it to see how the code interacts.

blocks|key|3025657|text|向你能找到的每个人寻求帮助，并让他们向他们认为可能有帮助的任何人寻求帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3025658|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Ask everyone you can find for help and ask them to ask anyone else they think could be helpful.

blocks|key|3239845|text|除了通读代码/数据模型之外，我一直学习的方法是开始修复一些bug。这让我接触到了系统的各个部分，在阅读代码时有了“目的”，让它变得更有意义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3239846|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The way I have always learned, besides just reading through the code / data model is to start fixing some bugs. That gives me exposure to various parts of the system, and having the 'purpose' while reading the code makes it a bit more meaningful.

blocks|key|3025687|text|有一些工具可以吸收源代码并绘制图片。试试来自Sparx的Enterprise+Architect。它的每个座位不到200美元，将非常有效地向您显示对象布局。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3025688|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are tools which suck up the source code and draw pictures. Try Enterprise Architect from Sparx. It's under $200 per seat and will show you the object layout very effectively.

blocks|key|299186|text|我是一名合同工程师，在过去的几十年里，这种情况每年都会发生几次。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|299187|我发现在查看任何代码之前，首先运行应用程序并使用它是非常有帮助的：|299188|299189|它到底是做什么的？如有必要，请阅读user+documentation.|unordered-list-item|299190|What+happens+with+extreme+program?|299191|Explore？|299192|如果我遗漏了一些值怎么办？|299193|如果我快速单击控件会发生什么？|299194|是否有任何方法可以在应用程序的边缘滥用program？|299195|Explore:是否有很少使用或难以找到的子菜单？|299196|299197|是否有可公开更多functionality?|299198|的配置工具|299199|当我这样做的时候，我正在构建一个我将如何实现它的心理模型。令人惊讶的是，这种以用户为导向的产品第一次接触通常会让我对应用程序的理解远远超过那些长期从事这项工作的开发人员。这种方法的一个副作用是，我倾向于发现相当多的错误(通常是相当多的错误)，并认为应该做出相当多的改进。|299200|然后，我将查看程序的一般结构，无论是模块、类、文件还是模式。不查看单独的代码行，除了那些显示程序架构的代码行。一旦我认为我理解了一半以上的结构，我就会尝试做一个小的bug修复或改进--这需要几分钟的时间来编写，但可能需要几个小时才能正确地理解。如果它正常工作，我会在某个地方做一个稍微大一点的更改，最好是在代码的另一个部分。|299201|通过这种方式，我发现可以很好地理解每天大约50,000到100,000行代码。|299202|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|1A|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|1C|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|1D|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|1E|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|1F|8|@]|9|@]|A|$]]|$1|T|3|-4|5|G|7|1G|8|@]|9|@]|A|$]]|$1|U|3|V|5|G|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1J|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1K|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1L|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|15|$]]

I'm a contract engineer, and this situation is routine several times per year—for the last few decades.

I find it quite helpful to first run the application and play with it—before looking at any code:

<ul>
<li>What the heck does it do? If necessary, read the user documentation.</li>
<li>What happens with extreme values?</li>
<li>What if I leave out some values?</li>
<li>What happens if I click on a control rapidly?</li>
<li>Is there any way to misuse the program?</li>
<li>Explore the edges of the application: are there seldom used or hard-to-find sub-menus? Is there a configuration facility which exposes more functionality?</li>
</ul>

While I'm doing that, I'm constructing a mental model of how I would have implemented it. Surprisingly, this user-oriented first encounter with the product usually causes my understanding of the application to be head and shoulders above the developers who have worked on it for a long time. A side effect of this approach is that I tend to find quite a few bugs (often quite an avalanche of them), and think of quite a few improvements which should be made.

After that, I look at the general structure of the program, whether it be modules, classes, files, or schema. Not looking at individual lines of code, except those showing the program's architecture. Once I think I understand over half of the structure, I try to make a small bug fix or improvement—something which takes a few minutes to write, but may take hours to properly understand. If it works, I make a slightly bigger change somewhere, preferably in another section of the code.

In this way, I've found it possible to understand well enough approximately 50,000 to 100,000 lines of code per day.

I have switched to a new company and I am working on a product that has a huge code base without documentation. I want to quickly get acquainted with the design and the code flow of the product so that I may become a productive member ASAP

Slowly and steadily one does gets to understand the code, but what should be the best and smart way one should approach the code base so that he understands the code quickly and start delivering?

Note: I tried my hands on Star UML and tried to reverse engineer the class diagrams so that I may have a rough idea of the product internal designs but failed miserably.

EDIT: The question is not about gaining knowledge about what the product does but how the internals are designed.

Fixing bugs and Debugging using breakpoints does provide one way of achieving this but I was looking if there is even a faster way we could achieve this

In Keith's Words:

<blockquote>
 This may work for some code-bases, but in general I think its a bad idea. You tend to be too focused on the details, while at first you want to get the big picture: what the classes are, what the communication patterns are, etc. Plus, if you have a distributed application (client-server, n-tier, etc), or code that takes a long time to run it may not be practical to run it through a debugger
</blockquote>

How to understand the design and code flow of any product quickly?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经换到了一家新公司，我正在开发一个产品，它有一个巨大的代码库，没有文档。我想快速熟悉产品的设计和代码流程，这样我就可以尽快成为一个有生产力的成员。慢慢地和稳定地理解代码，但是什么是最好的和聪明的方法来接近代码库，以便他快速理解代码并开始交付？注意：我尝试过使用Star UML，并试图对类图进行逆向工程，这样我就可以...

问如何快速理解任何产品的设计和代码流？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何快速理解任何产品的设计和代码流？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何快速理解任何产品的设计和代码流？
EN