本文是小编为大家收集整理的关于如何快速了解任何产品的设计和代码流程？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我已经换到了一家新公司，我正在开发一种产品，该产品具有庞大的代码库而没有文档.我想快速熟悉产品的设计和代码流程，以便尽快成为一名高效的成员
人们确实可以缓慢而稳定地理解代码，但是应该以最佳和聪明的方式接近代码库，以便他快速理解代码并开始交付?
注意:我尝试了 Star UML 并尝试对类图进行逆向工程，以便对产品内部设计有一个粗略的了解，但惨遭失败.
编辑:问题不在于了解产品的功能，而在于了解内部结构.
使用断点修复错误和调试确实提供了一种实现这一目标的方法，但我正在寻找是否有更快的方法可以实现这一目标
用基思的话来说:
<块引用>这可能适用于某些代码库，但总的来说我认为这是一个坏主意.您往往过于关注细节，而起初您想了解全局:类是什么，通信模式是什么等.另外，如果您有一个分布式应用程序(客户端-服务器，n 层)等)，或者需要很长时间才能运行的代码，通过调试器运行它可能不切实际
推荐答案
我是一名合同工程师，在过去的几十年里，这种情况每年都会发生几次.
我发现在查看任何代码之前先运行应用程序并使用它很有帮助:
- 它到底有什么作用?如有必要，请阅读用户文档.
- 极端值会发生什么?
- 如果我遗漏了一些值怎么办?
- 如果我快速点击一个控件会发生什么?
- 有什么方法可以滥用程序吗?
- 探索应用程序的边缘:是否有很少使用或难以找到的子菜单?是否有提供更多功能的配置工具?
在我这样做的同时，我正在构建一个我将如何实施它的心智模型.令人惊讶的是，这种以用户为导向的第一次接触产品通常使我对应用程序的理解远高于长期从事该应用程序的开发人员.这种方法的一个副作用是，我往往会发现相当多的错误(通常是雪崩式的)，并想到很多应该进行的改进.
之后，我会查看程序的一般结构，无论是模块、类、文件还是模式.不查看单独的代码行，除了那些显示程序架构的代码.一旦我认为我理解了一半以上的结构，我就会尝试做一个小的错误修复或改进——这需要几分钟来写，但可能需要几个小时才能正确理解.如果可行，我会在某处进行稍微大一点的更改，最好是在代码的另一部分.
通过这种方式，我发现每天可以很好地理解大约 50,000 到 100,000 行代码.
问题描述
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:
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
推荐答案
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:
- What the heck does it do? If necessary, read the user documentation.
- What happens with extreme values?
- What if I leave out some values?
- What happens if I click on a control rapidly?
- Is there any way to misuse the program?
- 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?
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.
更多相关问答
联系站长