至于可视化工具，如果涉及到数据库的话，我会从数据库设计开始。 Microsoft Visio 等工具可以从现有数据库创建图表。我发现了解数据库的设计可以帮助我理解程序员想要完成的任务。 Visio 还适合使用一些基本流程图来记录程序流程，尽管您必须自己创建它们 - 据我所知，它不会自动生成它们。
祝你好运。
If you have a chance, I'd try and talk to the original designers and developers. Ask them about any major design issues or shortcomings of the project. Is the project in good shape and only needs maintenance or are there major components that need to be added or reworked? What are going to be the biggest roadblocks to maintaining the project? Take one or two of them to lunch (separately) if you have a budget for it as they might be more free to talk about problems outside of the office.
Talking to the users is also important for getting a feel for the current status of the project. Quite often they have a different opinion of how things stand then the developers do. Make sure, however, that they don't start giving you a list of all the things they want added or changed - you should take a few weeks to understand the project before you can start making major changes to it.
As for visualization tools, I'd start with the database design if there is a database involved. Tools like Microsoft Visio can create a diagram from an existing database. I find knowing the design of the database helps me wrap my head around what the programmers were trying to accomplish. Visio is also good for documenting program flow with some basic flowcharts though you'll have to create them yourself - it doesn't generate them automatically as far as I know.
Use Profiler to see main functions and events in your project (the fastest way to learn framework)
Learn business logic very well to better understand the code
Documenting every new thing you learn - setup wiki (you will be surprised how quickly things are forgotten)
You can use Visio to draw Database Model Diagrams. (keep them close to you while studying the code)
These are the things that helped me when I inherited the previous project (50+ developers, 70+ GB database, 1 GB of source code and not even a single line of comments in code (maybe few :), and everything written in foreign language )
Try to find the starting point of the system and start digging from there. It sort of sucks to be in that situation, and chances are the comments might not be that helpful either. If the original developers didn't bother (or didn't have the chance) to document, chances are they never kept the comments up to date with code changes.
So time to bring the shovel... but don't just dig in blindly. One thing that is important is to understand what the system does from a users' perspective.
Concurrent with your code digging, you need to meet with a user (or the users' liason) and have him walk through the system, showing you how it is supposed to be used, for what purpose and what it and its subsystems are supposed to do. Moreover, attempt to understand what are the business pre-conditions and post-conditions of each major operation performed with this system.
Then map (or do a hierarchical) chart of the main functions of the system; classify them by category, purpose or module. If the system performs some sort of work flows or business transactions, attempt to chart some sort of state/transition diagram documenting each (and cross-referencing each state/transition to the subsystem or module in the system that is in charge for it.)
Once you have that, you can dig according to function. It will be best if you dig for a specific purpose, say, there is a bug fix to implement. You locate the logical module or category pertaining to that bug fix, you have the pre-conditions and post-conditions; then you can dig precisely on (or around) that bug fix.
If you just dig in without a guide (at least a high level one), you can be digging for months without getting anywhere (I'm telling you from painful experience.)
If there is no user manual, implement a draft according to your meetings with the users/users' liason. That could serve as a guide for implementing a developer's/administrator's manual for the system you just inherited (if there is ever a chance to implement one.)
If code is not on source control, put it on it. Doesn't matter what SCS you pick (could even be CVS, yuck!) What matters is to put it under source control asap.
Those developers didn't exist in a vacuum, they must have had exchanged emails. Identify other tech liasons they work with. Attempt to identify what other systems, if any, this system interfaces to (.ie. your databases, other's peoples databases, cron jobs, etc.)
But this could come at a later time. I think you should, for starters, focus on understanding how to use the system and what it is for. Let's call it understanding its business/knowledge architecture. Then dig according to that... or better yet, according to that and with the purpose of fixing a bug.
Use the debugger to walk through the application. That will let you go both deep and wide. You'll also be able to learn about how the code handles specific scenarios.
When you're ready to change something as @Jaxidian said, Working Effectively with Legacy Code is a great resource.
I was recently in a similar situation. What helped in my case was focusing on the changes I needed to perform on the project, and in the process of making those changes I learned about how the project is structured and so on. Sure, the first few tasks took a bit longer, but look on the bright side: I got stuff done and I got familiar with the project at the same time.
Whenever I start a new project, I spend 2-3 days skim reading the code and making notes. I basically go through the entire solution from top to bottom and make a map in a text editor of each (significant) class in each project and what it appears to do.
The aim in doing this is not to completely understand the entire codebase, so don't worry if you feel you are not getting your head around it completely. The aim is that you end up with an index of where to go when you need to start on your first piece of work. You should also end up with a cursory picture of the solution in the back of your brain that will get filled in over the next couple of months. I always do this on the first few days as your superiors will not expect you to be productive during this time and you may never get another opportunity where you have the time to do so.
Also, do not rely on code comments for direction. Even with the best intentions they are often unmaintained and may lead to incorrect conclusions about what a class or section of code may do: a comment may lie but the code always tells the truth.
Presuming there is a database, start with the data model. Somewhere (Mythical Man-Month?) it was written "if I have your tables, I don't need to see your code."
Be productivity-driven. In other words, find a change that needs doing and use this to learn how that bit of the system works. Your changes may not be the most elegant without a whole-picture understanding of the software, but you will get work done within days/weeks.
Follow things from the user-interface. I.e if a change involves things a user does on a dialog, find that dialog in the code (relatively easy) and then work backwards to see what bits of the code provide data to the dialog, how the dialog interacts with the system, etc. Trying to find "where does X happen in the code" is very hard without good documentation, but finding "where is the code relating to this dialog" is quite easy and gives you an entry-point into the code.
If you already have a team, you could charge each with a part of framework, and the result of their exploration should be registered somewhere, like a wiki. After that, give to each a task similar to something which is already done in the system (from the functional point of view)
For example: if a list of products is displayed in your app, you could display a list of orders (the complexity should be approximately the same), in the same manner it's done actually in the app. Than make it more interesting: try to edit it and save into DB.
Than switch the tasks and let the questions appear and than the first person who made the same task will show & explain how things are done.
Like that you'll see how the things are done pretty easy + your team will be up to date with this knowledge.
关于潜在的工具，您可能需要查看NDepend。它是一个代码分析工具，重点是突出代码库的内部组织和依赖关系（请参阅这篇文章了解典型输出），并发现代码质量问题。我个人没有使用过它，但该产品的开发人员之一 Patrick Smacchia 有一些帖子，他将 NDepend 应用于一些经典应用程序 (这里是 NUnit 例如）并讨论了它的含义，我找到了它们有趣的。
Regarding potential tools, you may want to look into NDepend. It is a code-analysis tool, with an emphasis on highlighting the internal organization and dependencies of the code base (see this post for typical outputs), and spotting code quality issues. I have not used it personally, but Patrick Smacchia, one of the developers of the product, has a few posts where he applies NDepend to some classic apps (here is NUnit for instance) and discusses what it means, and I found them interesting.
Go and speak to the users or, read the manual and / or if one exists, go on a training course for the system (internal training departments will sometimes have put them together if there are lots of users).
If you don't know what it's meant to be doing then the chances of you being able to work out how it does it are close to zero.
发布评论
评论（14）
如果有机会，我会尝试与原始设计师和开发人员交谈。询问他们该项目的任何主要设计问题或缺点。该项目是否状况良好，仅需要维护，或者是否有主要组件需要添加或返工？维持该项目的最大障碍是什么？如果您有预算，请带其中一两个人（单独）共进午餐，因为他们可能更自由地谈论办公室外的问题。
与用户交谈对于了解项目的当前状态也很重要。他们对事情的看法常常与开发人员不同。但是，请确保他们不会开始向您提供他们想要添加或更改的所有内容的列表 - 您应该花几周的时间来了解该项目，然后才能开始对其进行重大更改。
至于可视化工具，如果涉及到数据库的话，我会从数据库设计开始。 Microsoft Visio 等工具可以从现有数据库创建图表。我发现了解数据库的设计可以帮助我理解程序员想要完成的任务。 Visio 还适合使用一些基本流程图来记录程序流程，尽管您必须自己创建它们 - 据我所知，它不会自动生成它们。
祝你好运。
If you have a chance, I'd try and talk to the original designers and developers. Ask them about any major design issues or shortcomings of the project. Is the project in good shape and only needs maintenance or are there major components that need to be added or reworked? What are going to be the biggest roadblocks to maintaining the project? Take one or two of them to lunch (separately) if you have a budget for it as they might be more free to talk about problems outside of the office.
Talking to the users is also important for getting a feel for the current status of the project. Quite often they have a different opinion of how things stand then the developers do. Make sure, however, that they don't start giving you a list of all the things they want added or changed - you should take a few weeks to understand the project before you can start making major changes to it.
As for visualization tools, I'd start with the database design if there is a database involved. Tools like Microsoft Visio can create a diagram from an existing database. I find knowing the design of the database helps me wrap my head around what the programmers were trying to accomplish. Visio is also good for documenting program flow with some basic flowcharts though you'll have to create them yourself - it doesn't generate them automatically as far as I know.
Good luck.
我鼓励您购买并阅读这本书彻底。它为您提供了这方面的大量信息，比您在这里找到的要多得多。
I would encourage you to buy and read this book thoroughly. It provides you a LOT of information in this regard, much more than you will find here.
为您集思广益：
使用调试器在应用程序中进行调试，针对您正在使用的任何语言使用静态代码分析工具...
与人们（包括开发人员和用户）交谈，以了解应用程序。
查看问题跟踪系统，看看您是否可以看到任何重复出现的问题类型...
Brainstorming a little for you:
Step around in the application with a debugger, use a Static Code Analysis tool for which ever language you are working with...
Talk with people - both developers AND USERS to get a feel of the application.
Review the issue tracking system to see if you can see any recurring types of problem...
最新的 Visual Studio 2010 允许您生成架构图< /a>.
http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/
The latest Visual Studio 2010 allows you to generate architecture diagrams.
http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/
这些是我继承之前项目时对我有帮助的东西（50+开发人员，70+ GB数据库，1 GB源代码，甚至代码中没有一行注释（也许很少:)，并且所有内容都是用外语语言编写的）
These are the things that helped me when I inherited the previous project (50+ developers, 70+ GB database, 1 GB of source code and not even a single line of comments in code (maybe few :), and everything written in foreign language )
尝试找到系统的起点并从那里开始挖掘。处于这种情况有点糟糕，而且评论可能也没有那么有帮助。如果最初的开发人员不费心（或没有机会）进行记录，那么他们很可能永远不会使注释与代码更改保持同步。
所以是时候带上铲子了……但不要盲目地挖。重要的一件事是从用户的角度理解系统的功能。
在挖掘代码的同时，您需要会见用户（或用户的联络人）并让他浏览系统，向您展示系统应该如何使用、用于什么目的以及系统及其子系统应该做什么做。此外，尝试了解使用该系统执行的每个主要操作的业务前置条件和后置条件是什么。
然后将系统的主要功能绘制成（或做层次结构）图；按类别、用途或模块对它们进行分类。如果系统执行某种工作流程或业务事务，请尝试绘制某种状态/转换图来记录每个流程（并将每个状态/转换交叉引用到系统中负责它的子系统或模块。）
掌握了之后，就可以根据功能进行挖掘了。如果您出于特定目的进行挖掘，例如要实施错误修复，那将是最好的。您找到与该错误修复相关的逻辑模块或类别，您拥有前置条件和后置条件；然后你就可以精确地挖掘（或围绕）该错误修复。
如果你只是在没有指南（至少是高级指南）的情况下进行挖掘，你可能会挖掘数月却一事无成（我是从痛苦的经验告诉你的。）
如果没有用户手册，请根据你的情况实施一个草案与用户/用户联络人的会议。这可以作为为您刚刚继承的系统实施开发人员/管理员手册的指南（如果有机会实施的话）。
如果代码不在源代码管理中，请将其放在上面。您选择什么 SCS（甚至可能是 CVS，恶心！）并不重要，重要的是尽快将其置于源代码控制之下。
这些开发人员并不是凭空存在的，他们一定交换过电子邮件。确定与他们合作的其他技术联络员。尝试确定该系统与哪些其他系统（如果有）接口（即您的数据库、其他人的数据库、cron 作业等），
但这可能会在以后发生。我认为，对于初学者来说，您应该专注于了解如何使用该系统及其用途。我们称之为理解其业务/知识架构。然后根据该挖掘......或者更好的是，根据该挖掘并以修复错误为目的。
祝你好运。
Try to find the starting point of the system and start digging from there. It sort of sucks to be in that situation, and chances are the comments might not be that helpful either. If the original developers didn't bother (or didn't have the chance) to document, chances are they never kept the comments up to date with code changes.
So time to bring the shovel... but don't just dig in blindly. One thing that is important is to understand what the system does from a users' perspective.
Concurrent with your code digging, you need to meet with a user (or the users' liason) and have him walk through the system, showing you how it is supposed to be used, for what purpose and what it and its subsystems are supposed to do. Moreover, attempt to understand what are the business pre-conditions and post-conditions of each major operation performed with this system.
Then map (or do a hierarchical) chart of the main functions of the system; classify them by category, purpose or module. If the system performs some sort of work flows or business transactions, attempt to chart some sort of state/transition diagram documenting each (and cross-referencing each state/transition to the subsystem or module in the system that is in charge for it.)
Once you have that, you can dig according to function. It will be best if you dig for a specific purpose, say, there is a bug fix to implement. You locate the logical module or category pertaining to that bug fix, you have the pre-conditions and post-conditions; then you can dig precisely on (or around) that bug fix.
If you just dig in without a guide (at least a high level one), you can be digging for months without getting anywhere (I'm telling you from painful experience.)
If there is no user manual, implement a draft according to your meetings with the users/users' liason. That could serve as a guide for implementing a developer's/administrator's manual for the system you just inherited (if there is ever a chance to implement one.)
If code is not on source control, put it on it. Doesn't matter what SCS you pick (could even be CVS, yuck!) What matters is to put it under source control asap.
Those developers didn't exist in a vacuum, they must have had exchanged emails. Identify other tech liasons they work with. Attempt to identify what other systems, if any, this system interfaces to (.ie. your databases, other's peoples databases, cron jobs, etc.)
But this could come at a later time. I think you should, for starters, focus on understanding how to use the system and what it is for. Let's call it understanding its business/knowledge architecture. Then dig according to that... or better yet, according to that and with the purpose of fixing a bug.
Good luck.
使用调试器来遍历应用程序。这会让你既深入又广泛。您还可以了解代码如何处理特定场景。
当您准备好像 @Jaxidian 所说的那样进行更改时，有效地使用旧代码是一个很好的资源。
Use the debugger to walk through the application. That will let you go both deep and wide. You'll also be able to learn about how the code handles specific scenarios.
When you're ready to change something as @Jaxidian said, Working Effectively with Legacy Code is a great resource.
我最近也遇到了类似的情况。对我的案例有帮助的是专注于我需要对项目执行的更改，并且在进行这些更改的过程中我了解了项目的结构等等。当然，前几项任务花费的时间有点长，但往好的方面看：我完成了工作并且我同时熟悉了该项目。
I was recently in a similar situation. What helped in my case was focusing on the changes I needed to perform on the project, and in the process of making those changes I learned about how the project is structured and so on. Sure, the first few tasks took a bit longer, but look on the bright side: I got stuff done and I got familiar with the project at the same time.
每当我开始一个新项目时，我都会花 2-3 天浏览代码并做笔记。我基本上从上到下浏览了整个解决方案，并在每个项目中的每个（重要）类及其似乎执行的操作的文本编辑器中制作了一个地图。
这样做的目的不是完全理解整个代码库，所以如果您觉得自己没有完全理解它，请不要担心。目的是当您需要开始第一份工作时，您最终会得到一个应该去哪里的索引。最后，你的大脑中还应该对解决方案有一个粗略的了解，并在接下来的几个月内得到补充。我总是在最初几天这样做，因为你的上级不会期望你在这段时间保持高效，而且你可能永远不会再有机会这样做。
另外，不要依赖代码注释来指导。即使有最好的意图，它们也常常得不到维护，并且可能会导致对代码的类或部分的功能得出错误的结论：注释可能会撒谎，但代码总是说实话。
Whenever I start a new project, I spend 2-3 days skim reading the code and making notes. I basically go through the entire solution from top to bottom and make a map in a text editor of each (significant) class in each project and what it appears to do.
The aim in doing this is not to completely understand the entire codebase, so don't worry if you feel you are not getting your head around it completely. The aim is that you end up with an index of where to go when you need to start on your first piece of work. You should also end up with a cursory picture of the solution in the back of your brain that will get filled in over the next couple of months. I always do this on the first few days as your superiors will not expect you to be productive during this time and you may never get another opportunity where you have the time to do so.
Also, do not rely on code comments for direction. Even with the best intentions they are often unmaintained and may lead to incorrect conclusions about what a class or section of code may do: a comment may lie but the code always tells the truth.
假设有一个数据库，从数据模型开始。在某个地方（神话人月？）它被写为“如果我有你的表，我不需要看到你的代码。”
Presuming there is a database, start with the data model. Somewhere (Mythical Man-Month?) it was written "if I have your tables, I don't need to see your code."
我建议两件事可能会有所帮助：
以生产力为导向。换句话说，找到需要进行的更改，并使用它来了解系统的该部分是如何工作的。如果没有对软件的全面了解，您的更改可能不是最优雅的，但您将在几天/几周内完成工作。
通过用户界面进行操作。即，如果更改涉及用户在对话框上执行的操作，请在代码中找到该对话框（相对容易），然后向后查看代码的哪些位向对话框提供数据、对话框如何与系统交互等。如果没有良好的文档，试图找到“X 在代码中发生的位置”是非常困难的，但是找到“与此对话框相关的代码在哪里”非常容易，并且为您提供了代码的入口点。
I'd suggest two things that may help:
Be productivity-driven. In other words, find a change that needs doing and use this to learn how that bit of the system works. Your changes may not be the most elegant without a whole-picture understanding of the software, but you will get work done within days/weeks.
Follow things from the user-interface. I.e if a change involves things a user does on a dialog, find that dialog in the code (relatively easy) and then work backwards to see what bits of the code provide data to the dialog, how the dialog interacts with the system, etc. Trying to find "where does X happen in the code" is very hard without good documentation, but finding "where is the code relating to this dialog" is quite easy and gives you an entry-point into the code.
如果你已经有一个团队，你可以向每个人收取一部分框架的费用，他们的探索结果应该注册在某个地方，比如维基百科。之后，给每个人一个类似于系统中已经完成的任务（从功能的角度来看）
例如：如果您的应用程序中显示产品列表，您可以显示订单列表（复杂性应该大致相同），其方式与应用程序中实际完成的方式相同。比让它更有趣：尝试编辑它并保存到数据库中。
然后切换任务并让问题出现，然后第一个完成相同任务的人将显示并显示问题。解释事情是如何完成的。
这样，您将看到事情是如何轻松完成的+您的团队将了解最新的知识。
If you already have a team, you could charge each with a part of framework, and the result of their exploration should be registered somewhere, like a wiki. After that, give to each a task similar to something which is already done in the system (from the functional point of view)
For example: if a list of products is displayed in your app, you could display a list of orders (the complexity should be approximately the same), in the same manner it's done actually in the app. Than make it more interesting: try to edit it and save into DB.
Than switch the tasks and let the questions appear and than the first person who made the same task will show & explain how things are done.
Like that you'll see how the things are done pretty easy + your team will be up to date with this knowledge.
关于潜在的工具，您可能需要查看NDepend。它是一个代码分析工具，重点是突出代码库的内部组织和依赖关系（请参阅这篇文章了解典型输出），并发现代码质量问题。我个人没有使用过它，但该产品的开发人员之一 Patrick Smacchia 有一些帖子，他将 NDepend 应用于一些经典应用程序 (这里是 NUnit 例如）并讨论了它的含义，我找到了它们有趣的。
Regarding potential tools, you may want to look into NDepend. It is a code-analysis tool, with an emphasis on highlighting the internal organization and dependencies of the code base (see this post for typical outputs), and spotting code quality issues. I have not used it personally, but Patrick Smacchia, one of the developers of the product, has a few posts where he applies NDepend to some classic apps (here is NUnit for instance) and discusses what it means, and I found them interesting.
去与用户交谈，或者阅读手册和/或如果有的话，参加系统培训课程（如果有很多用户，内部培训部门有时会将它们放在一起）。
如果您不知道它的用途，那么您能够弄清楚它是如何工作的机会几乎为零。
Go and speak to the users or, read the manual and / or if one exists, go on a training course for the system (internal training departments will sometimes have put them together if there are lots of users).
If you don't know what it's meant to be doing then the chances of you being able to work out how it does it are close to zero.