了解和修改大型项目
我是一名新手程序员，作为我项目的一部分，我必须修改一个开源工具（用 java 编写），该工具有数百个类。我必须修改其中的很大一部分以满足项目的需要。在过去的一个月里，我一直在努力阅读代码，试图找出每个类的功能，并试图找出从开始到结束的管道。
80% 的课程文档不完整/缺失。剩下的 20% 是构成该工具通用 API 的部分。 一个月的代码阅读让我了解了基本架构。但我无法弄清楚我需要为我的项目做出哪些确切的改变。有一次，我开始修改一部分代码，很快就做出了很多修改，以至于我已经记不清了。
一位朋友建议我尝试写下类层次结构。有没有更好的（标准？）方法来做到这一点？
I am a novice programmer and as a part of my project I have to modify a open source tool (written in java) which has hundreds of classes. I have to modify a significant part of it to suit the needs of the project. I have been struggling with it for the last one month trying to read code, trying to find out the functionalities of each class and trying to figure out the pipeline from start to end.
80% of the classes have incomplete/missing documentation. The remaining 20% are those that form the general purpose API for the tool.
One month of code reading has just helped me understand the basic architecture. But I have not been able to figure out the exact changes I need to make for my project. One time, I started modifying a part of the code and soon made so many changes that I could no longer remember.
A friend suggested that I try to write down the class hierarchy. Is there a better(standard?) way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
有一本很棒的书，名为有效使用旧代码 ，作者：迈克尔·费瑟斯。 此处有一个较短的文章版本。
他的观点之一是，你能做的最好的事情就是为现有代码编写单元测试。这可以帮助您了解入口点在哪里以及代码应该如何工作。然后它可以让您重构它，而不必担心会破坏它。
从链接的文章中，他的策略总结如下：
There's a great book called Working Effectively with Legacy Code, by Michael Feathers. There's a shorter article version here.
One of his points is that the best thing you can do is write unit tests for the existing code. This helps you understand where the entry points are and how the code should work. Then it lets you refactor it without worrying that you're going to break it.
From the article linked, the summary of his strategy:
Eclipse（以及其他 IDE）提供了两件事来“对抗”这个问题。我在非常大的项目中使用过它们：
调用层次结构 - 右键单击一个方法并选择“调用层次结构”，或使用 CTRL + ALT + H。这将为您提供调用所选方法的所有方法，并可以选择进一步检查树。此功能确实非常有用。
类型层次结构 - 查看类的继承层次结构。在 Eclipse 中是 F4 或 CTRL + T。
另外：
Two things that Eclipse (and other IDEs as well) offer to 'fight' this. I've used them on very large projects:
Call hierarchy - right-click a method and choose "call hierarchy", or use CTRL + ALT + H. This gives you all methods that call the selected method, with option to check further down the tree. This feature is really very useful.
Type hierarchy - see the inheritance hierarchy of classes. In eclipse it's F4 or CTRL + T.
Also:
我的朋友，你已经陷入困境了。修改大型、记录不良的遗留代码是让经验丰富的程序员认真思考销售保险或其他替代职业的乐趣的项目之一。但这并非不可能，这里有一些建议，希望对您有所帮助。
您的首要任务是尽可能多地理解代码。你至少走在正确的轨道上。了解类结构绝对重要，而图表可能是最好的方法。我建议的另一件事是，当您发现类的作用时，请自己添加缺少的文档。这样当你回来时你就不会忘记你发现了什么。
不要忘记调试器。如果您想了解到底发生了什么，单步执行相关代码，或者只是了解调用堆栈在某个点的实际情况会非常有帮助。
My friend, you are in deep doodoo. Modifying large, badly documented legacy code is one of those projects that makes experienced programmers seriously contemplate the joys of selling insurance, or some other alternative career. However it isn't impossible, and here are some tips that I hope will help.
Your first task is to understand the code as much as possible. You are at least on the right track there. Getting a good idea of the class structure is absolutely important, and a diagram is probably the best way. The other thing I would suggest is that when you find out what a class does, add the missing documentation yourself. That way when you come back to it you wont' have forgotten what you found out.
Don't forget the debugger. If you want to find out what is really going on, stepping through the relevant code, or simply finding out what a call stack really looks like at a certain point can be very helpful.
理解代码的唯一方法就是阅读它。继续工作，这是我的建议。
有些项目的文档比其他项目更好。以下是我知道组织良好的几个项目：
Tomcat ,
码头，
Hudson，
您应该检查java-source 了解更多开源项目。
The only way to understand code is to read it. Keep working that is my advice.
There are projects with better documentation than others. Here is a couple of projects that I know are well organized:
Tomcat ,
Jetty,
Hudson,
You should check java-source for more open source projects.
我个人认为尝试一下子理解整个应用程序是非常困难的。相反，尝试只关注某些模块。例如，如果您可以识别需要更改的模块（例如，基于屏幕或某些输入/输出点），那么首先进行一个小的更改并对其进行测试。从那里开始，进行一些小的改变、测试，然后继续。
此外，如果您的项目有单元测试（认为自己很幸运），请检查您关注的模块的单元测试。这将帮助您了解该模块的预期用途。
Personally I think it is very difficult to try to understand an entire application all at once. Instead, try to focus only on certain modules. For example, if you can identify a module that you need to change (e.g. based on a screen, or certain input/output point), then start by making one small change and testing it. Go from there, making a small change, testing, and moving on.
Additionally, if your project has unit tests (consider yourself lucky) and review the unit tests of the module you are focusing on. That will help you get an idea of what the module is expected to do.
在我看来，没有标准的方法来理解项目。这取决于许多因素，从您正在分析的代码/架构的可理解性到您以前在大型项目上的经验。
我建议你使用建模工具对代码进行逆向工程，这样你就可以从现有的源代码生成一些UML模型。在分析代码期间，这些图表可以作为图形指南很有帮助。
不要害怕使用调试来获取项目最复杂功能的逻辑。逐条指令运行最复杂的代码，查看变量的确切值以及对象之间的交互可能会有所帮助。
在重构以更改项目以满足您的需求之前，请务必编写一些测试用例，以便您可以验证您的修改不会以意外的方式破坏代码。
In my opinion there is no standard approach to understand a project. It depends on many factors, from the understandability of the code/architecture you're analyzing to your previous experience on large projects.
I suggest you to reverse-engineer the code by using a modeling tool, so that you can generate some UML models from the existing source code. These diagrams can be helpful as a graphic guideline during your anaysis of the code.
Don't be afraid to use debugging to grab the logic of the most complex functionalities of the project. Running the most complex code instruction by instruction, seeing the exact values of the variables and the interactions between the objects can be helpful.
Before you refactor to change the project to suit your needs, be sure to write some test cases, so that you can verify that your modifications don't break the code in unexpected ways.
这里有一些建议
这样如果你开始做出改变
你可以随时回顾过去
版本。
已经学会/经历过。 Javadoc 没问题
为了这。
有很多插件可以为您提供代码布局的良好表示。
Here are a couple recommendations
This way if you start making changes
you can always look back at previous
versions.
have already learned/gone through. Javadoc is fine
for this.
There are lots of plugins out there and wil give you a nice representation of your code layout.