我想知道经验，当我们需要更多地接管其他人的软件项目时，以便原始软件开发人员已经辞职。

解决方案

我们获得的最大成功就是" wiki"了一切。在通知期内，请即将离任的开发人员记录团队/公司Wiki中的所有内容，并查看我们是否可以与他/她进行代码审查，并在对代码进行解释的同时对代码添加评论。最适合"接管"开发人员在离开者的监督下在代码中编写注释。

实际上，我们必须要有一组特定的"可交付成果"才能接手一个项目。

如果有机会，我们将首先尝试在开发该项目的团队中邀请一个人。这样我们就可以在小组接管代码之前获得一些第一手的知识。 (在@Guy所写的行中)

话虽如此，对我来说最重要的部分是：

• 该代码的某种高级概述(绘图？)。
• 轻松访问实际编写代码的人的问题

这对我来说是接管代码和项目时的alpha omega

最原始的开发人员在移交项目之前离开的情况总是最有趣的：我们陷入了未知状态的代码库。我经常发现有趣的是，新开发人员通常如何尽最大的努力来评论代码的设计不良：他们忘记了旧开发人员可能受到的限制，他们可能被迫做出的快捷方式。俗话总是老派==坏派。你们如何看待：
我什至把这称为官方的不良做法：对我们之前的人说脏话。

我尝试采用尽可能务实的方法：学习代码库，四处逛逛。尝试理解需求和代码之间的关系，即使根本没有明确的初始关系。当我们意识到为什么他们这样做或者那样做时，总会有"啊哈时刻"。如果我们仍然确信某些事情是通过错误的方式实现的，那么请尽可能进行重构。并隔离我们无法更改的代码段：使用模拟框架对它们进行单元测试。

向维护开发人员致敬。

我曾经加入一个团队，该团队已从外包中移交了一大堆废话。最初的项目是一个基于Java，Struts，Hibernate | Oracle的多媒体内容管理器，结构合理(似乎是几个人的工作，结对编程，明智地使用设计模式以及一些单元测试)。然后其他人继承了该项目，并不断复制粘贴功能，放松了业务规则，进行了修补，分支，直到它变成了巨大的意大利面怪物，并带有以下精心编写的代码：

List<Stuff> stuff = null; 
if (LOG.isDebugEnabled())
{
    stuff = findStuff();
    LOG.debug("Yeah, I'm a smart guy!");
    for (Stuff stu : stuff)
    {
        LOG.debug("I've got this stuff: " + stu);
    }
} 
methodThatUsesStuff(stuff);

隐藏在其他聪明才智之中。

我通过患者重构(更多时间提取方法和类)来驯服野兽，不时评论代码，重新组织一切，直到代码库缩小30％，随着时间的推移变得越来越可管理。

我不得不几次接管其他人的不同质量等级的代码。因此，提示：

• 努力从第一分钟开始记录下任何重要信息的结构化注释：利益相关者的姓名，业务规则，代码和文档位置等。最好专门使用一本新的螺旋笔记本，这样就可以在需要时撕掉页面。
• 利用市场上提供的更好的免费索引和桌面搜索工具之一(Google桌面搜索，MS Windows搜索均可)。向其添加所有文档，电子邮件，代码位置。
• 在开发任何内容之前，都要进行文档分析：找到可以通过网络以电子方式进行操作并打印出文档的所有内容，并努力阅读。甚至在未完成的草稿中，也有很多有用的信息。
• 随心所欲映射代码，体系结构等。
• 使用较少记录和维护的系统，我们不可避免地会感到绝望，这很可能会使我们陷入拖延的状态。尤其是在头几天或者一周内，我们需要消化的大量新信息不胜枚举。在这些时候，很高兴有人提醒我们(或者自己动手做)轻松一点，先专心于重要的事情，然后转而采取较小的步骤来试图获得了解，而不是试图向前迈进。
• 继续做笔记，绘制图表，绘制丰富的图片，进行思维导图。它确实有助于消化大量的新信息，大部分都是杂乱无章的。

嘿，祝你好运！