3

当你需要接管别人的软件项目时，我想知道你的经验——尤其是当最初的软件开发人员已经辞职时。

4

5 回答 5

5

我们在这方面取得的最大成功就是“维基”所有内容。在通知期间，请离开的开发人员帮助您记录团队/公司 wiki 中的所有内容，看看您是否可以与他/她一起进行代码审查，并在进行解释部分的审查时向代码添加注释。最适合“接管”的开发者在离开者的监督下写代码中的注释。

于 2008-09-24T06:37:39.163 回答
3

原始开发人员在移交项目之前离开的情况总是最有趣的：您被困在未知状态的代码库中。我总是觉得有趣的是，新开发人员经常尽最大努力评论代码设计的糟糕程度：他们忘记了旧开发人员可能受到的约束，他们可能被迫做出的捷径。谚语总是Old dev == bad dev。你们怎么看：我什至认为这是一种官方的坏习惯：对我们之前的人说坏话。

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

向维护开发人员致敬。

于 2008-09-24T07:08:12.833 回答
3

我曾经加入过一个团队，该团队被外包给了一堆热气腾腾的废话。最初的项目 - 基于 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%，随着时间的推移变得越来越易于​​管理。

于 2008-09-24T10:35:47.327 回答
1

我不得不多次接管别人的不同质量的代码。因此提示：

  • 努力从第一分钟开始对任何重要信息进行结构化记录：利益相关者的姓名、业务规则、代码和文档位置等。最好专门使用一个新的螺旋笔记本，这样你可以在必要时撕掉页面。

  • 使用市场上更好的免费索引和桌面搜索工具之一（Google 桌面搜索、MS Windows 搜索都可以）。将所有文档、电子邮件、代码位置添加到其中。

  • 在开发任何东西之前进行文档分析：找到所有可以在网络上以电子方式获得的东西并打印出文档，努力简单地阅读它。即使在未完成的草稿中，也有许多有用的信息。

  • 随心所欲地对代码、架构等进行思维导图。

  • 由于记录和维护较少的系统，您不可避免地会感到绝望，这可能会使您陷入拖延模式。尤其是在你的第一天或第一周，你的大脑必须消化大量的新信息。在这些时候，很高兴有人提醒你（或自己做）放轻松，首先专注于重要的事情，然后重新采取更小的步骤来试图获得理解，而不是试图向前飞跃。

  • 不断记笔记、制作图表、绘制丰富的图片、思维导图。它确实有助于消化大量的新信息，这些信息大多是杂乱无章的。

嘿，祝你好运！

于 2008-09-29T14:50:21.407 回答
0

我们实际上有一组指定的“可交付成果”，我们必须在场才能接管一个项目。

如果我们有机会，我们首先会尝试在开发项目的团队中推动我们的一个人。这样我们就可以在我们的团队接管代码之前获得一些第一手的知识。（在@Guy 写的那一行）

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

  • 某种代码的高级概述（绘图？）。
  • 轻松访问向实际编写代码的人提问

这对我来说是接管代码和项目时的阿尔法欧米茄

于 2008-09-24T06:56:09.883 回答