你如何处理大型项目？

Question

我刚刚继承了一个以前由大约4-5人编码的大型项目。文档由注释组成，编写得不是很好。我必须了解这个项目的最新情况。我该如何开始？它由许多不同的源文件组成。你刚刚挖进去吗？是否有可以帮助可视化结构/流程的工具？

Answer 1

如果您有机会，我会尝试与原始设计师和开发人员交谈。询问他们有关项目的任何重大设计问题或缺点。项目是否状态良好，只需要维护，还是需要添加或重新加工的主要部件？什么是维持该项目的最大障碍？如果你有预算，可以带一两个人共进午餐（另外），因为他们可能会更自由地谈论办公室以外的问题。

与用户交谈对于了解项目的当前状态也很重要。他们常常对开发人员的工作方式有不同的看法。但是，请确保他们没有开始为您提供他们想要添加或更改的所有内容的列表 - 您应该花几周的时间来了解项目，然后才能开始对其进行重大更改。

对于可视化工具，如果涉及数据库，我将从数据库设计开始。像Microsoft Visio这样的工具可以从现有数据库创建一个图表。我发现知道数据库的设计可以帮助我了解程序员想要完成的任务。 Visio也适用于使用一些基本流程图来记录程序流程，但您必须自己创建它们 - 据我所知，它不会自动生成它们。

祝你好运。

Answer 2

我鼓励您购买并阅读this book thoroughly。它为您提供了很多这方面的信息，远远超出了您的所在。

Answer 3

为你做一点头脑风暴：

使用调试器在应用程序中四处走动，使用静态代码分析工具，使用您正在使用的语言...

与人们交流 - 开发人员和用户都可以了解应用程序。

查看问题跟踪系统，看看是否可以看到任何反复出现的问题......

Answer 4

  

是否有可以提供帮助的工具   可视化结构/流程？

最新的Visual Studio 2010允许您生成architecture diagrams。

http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/

Answer 5

尝试找到系统的起点并从那里开始挖掘。在那种情况下有点糟糕，评论可能也没那么有用。如果原始开发人员没有打扰（或没有机会）进行记录，那么他们很可能永远不会更新代码更新。

所以有时间带上铲子......但不要盲目地挖掘。有一点重要的是从用户的角度理解系统的作用。

与您的代码挖掘同时进行，您需要与用户（或用户的liason）会面并让他遍历系统，向您展示它应该如何使用，用于何种目的以及它及其子系统应该做的。此外，尝试了解使用该系统执行的每项主要操作的业务前提条件和后置条件。

然后映射（或做一个分层）系统主要功能的图表;按类别，目的或模块对它们进行分类。如果系统执行某种工作流程或业务事务，请尝试绘制记录每个状态/转换图表的某种状态/转换图表（并交叉引用每个状态/转换到系统中负责它的子系统或模块。）

一旦你有了，你可以根据功能挖掘。最好是你挖掘一个特定的目的，比如，有一个bug修复实现。您找到与该错误修复有关的逻辑模块或类别，您有前置条件和后置条件;那么你可以准确地挖掘（或周围）那个bug修复。

如果你只是在没有向导的情况下深入挖掘（至少是高级别的），你可以挖掘数月而不会到达任何地方（我告诉你痛苦的经历。）

如果没有用户手册，请根据您与用户/用户联盟的会议实施草稿。这可以作为实现您刚刚继承的系统的开发人员/管理员手册的指南（如果有机会实现的话。）

如果代码不在源代码管理中，请将其置于其上。无论你选择什么样的SCS（甚至可能是CVS，都好！）重要的是尽快将其置于源代码管理之下。

那些开发人员并不存在于真空中，他们必须交换过电子邮件。找出他们合作的其他技术理由。尝试识别此系统与其他系统（如果有）的接口（例如，您的数据库，其他人的数据库，cron作业等）

但这可能会在以后发生。我认为，对于初学者来说，你应该专注于理解如何使用系统及其用途。让我们称之为理解其业务/知识架构。然后根据那个......或者更好的方式进行挖掘，根据这一点，以及修复错误的目的。

祝你好运。

Answer 6

1. 使用Profiler查看项目中的主要功能和事件（学习框架的最快方法）
2. 非常了解业务逻辑以更好地理解代码
3. 记录您学到的每一件新事物 - 设置wiki（您会惊讶于事情被遗忘的速度）
4. 您可以使用Visio绘制数据库模型图。 （在研究代码时让他们靠近你）

这些是我继承上一个项目时帮助我的东西（50多个开发人员，70多GB的数据库，1 GB的源代码，甚至代码中没有一行注释（可能很少:)，以及所写的一切在外国语言）

Answer 7

使用调试器遍历应用程序。这将让你深入和广泛。您还将能够了解代码如何处理特定方案。

当你准备好改变某些内容时@Jaxidian说，有效地使用旧版代码是一个很好的资源。

Answer 8

我最近处于类似情况。在我的案例中有所帮助的是关注我需要在项目上执行的更改，并且在进行这些更改的过程中，我了解了项目的结构等等。当然，前几个任务需要更长的时间，但是看起来很光明：我做完了和我同时熟悉项目 。

Answer 9

我建议两件事可能会有所帮助：

• 以生产力为导向。换句话说，找到需要做的更改并使用它来了解系统的这个位是如何工作的。如果没有对软件的全面了解，您的更改可能不是最优雅的，但您将在几天/几周内完成工作。

• 从用户界面开始关注。即如果更改涉及用户在对话框中执行的操作，则在代码中找到该对话框（相对简单），然后向后工作以查看代码的哪些位向对话框提供数据，对话框如何与系统交互等。如果没有良好的文档，试图找到“X在代码中发生的位置”是非常困难的，但是找到“与此对话框相关的代码在哪里”非常简单，并为您提供了代码的入口点。

  < / LI>

Answer 10

每当我开始一个新项目时，我会花2-3天时间浏览代码并做笔记。我基本上从上到下遍历整个解决方案，并在每个项目中每个（重要）类的文本编辑器中创建一个映射，以及它看起来要做什么。

这样做的目的不是要完全理解整个代码库，所以如果您觉得自己没有完全理解它，请不要担心。目的是当你需要开始第一件工作时，你最终得到了一个指数。您最终还应该粗略地了解大脑后部的解决方案，并在接下来的几个月内完成。我总是在最初几天这样做，因为你的上级不会期望你在这段时间内保持高效，你可能再也没有机会有时间这样做了。

此外，不要依赖代码注释方向。即使有最好的意图，它们通常也是不受维护的，并且可能导致关于代码类或代码段可能做什么的错误结论：评论可能存在，但代码总是说实话。

Answer 11

如果你已经有一个团队，你可以向每个团队收取一部分框架，他们的探索结果应该在某个地方注册，比如wiki。在此之后，为每个任务提供类似于已在系统中完成的任务（从功能的角度来看）

例如：如果您的应用中显示了产品列表，您可以显示订单列表（复杂性应该大致相同），就像它实际上在应用程序。比它更有趣：尝试编辑它并保存到数据库中。

然后切换任务并让问题出现，而第一个完成相同任务的人将显示＆amp;解释事情是如何完成的。

就像那样，你会看到事情的完成情况非常简单+你的团队将掌握这些知识。

Answer 12

假设有一个数据库，从数据模型开始。在某个地方（神话人月？），它被写成“如果我有你的桌子，我不需要看你的代码。”

Answer 13

关于潜在工具，您可能需要查看 NDepend 。它是一种代码分析工具，重点是突出代码库的内部组织和依赖关系（see this post用于典型输出），并发现代码质量问题。我没有亲自使用它，但该产品的开发人员之一Patrick Smacchia有一些帖子，他将NDepend应用于一些经典应用程序（here is NUnit for instance）并讨论它的含义，我发现它们很有趣。

Answer 14

去与用户交谈，或者阅读手册和/或如果存在，请继续进行系统培训课程（如果有很多用户，内部培训部门有时会将它们放在一起）。

如果你不知道它的意图是什么，那么你能够弄清楚它是如何做到的几率几乎为零。