我已经切换到一家新公司,我正在开发一个拥有巨大代码库但没有文档的产品.我想快速熟悉产品的设计和代码流程,以便尽快成为高效的会员
慢慢地,稳定地了解代码,但应该是最好和最聪明的方法应该接近代码库,以便他能够快速理解代码并开始交付?
注意:我尝试使用Star UML,并尝试对类图进行逆向工程,以便我可能对产品内部设计有一个大概的想法,但却失败了.
编辑:问题不在于了解产品的作用,而是如何设计内部结构.
使用断点修复错误和调试确实提供了实现此目的的一种方法,但我在寻找是否有更快的方法来实现这一点
在凯斯的话中:
这可能适用于某些代码库,但总的来说,我认为这是一个坏主意.你往往过于专注于细节,而一开始你想要了解大局:类是什么,通信模式是什么,等等.另外,如果你有一个分布式应用程序(客户端 - 服务器,n层)等等,或者需要很长时间才能运行它的代码可能不适合通过调试器运行它
wal*_*lyk 18
我是一名合同工程师,在过去的几十年里,这种情况每年都要例行几次.
在查看任何代码之前,我发现首先运行应用程序并使用它非常有用:
在我这样做的时候,我正构建一个我将如何实现它的心理模型.令人惊讶的是,这种以用户为导向的第一次与产品相遇通常会使我对应用程序的理解在长期处理它的开发人员之上.这种方法的一个副作用是我倾向于发现相当多的错误(通常是雪崩),并且想到应该做出的一些改进.
之后,我会看一下程序的一般结构,无论是模块,类,文件还是模式. 不看单独的代码行,除了那些显示程序架构的代码.一旦我认为我理解了超过一半的结构,我会尝试进行小错误修复或改进 - 这需要花费几分钟时间来编写,但可能需要数小时才能正确理解.如果它工作,我会在某处做一个稍大的改动,最好是在代码的另一部分.
通过这种方式,我发现每天可以很好地理解大约50,000到100,000行代码.
如果你有一个开发环境来以最好的方式运行代码,我发现使用调试器并在执行代码时观察代码流.您可以设置断点并逐步执行它以查看代码如何交互.