当你需要接管别人的软件项目时,我想知道你的经验——尤其是当最初的软件开发人员已经辞职时。
5 回答
我们在这方面取得的最大成功就是“维基”所有内容。在通知期间,请离开的开发人员帮助您记录团队/公司 wiki 中的所有内容,看看您是否可以与他/她一起进行代码审查,并在进行解释部分的审查时向代码添加注释。最适合“接管”的开发者在离开者的监督下写代码中的注释。
原始开发人员在移交项目之前离开的情况总是最有趣的:您被困在未知状态的代码库中。我总是觉得有趣的是,新开发人员经常尽最大努力评论代码设计的糟糕程度:他们忘记了旧开发人员可能受到的约束,他们可能被迫做出的捷径。谚语总是Old dev == bad dev。你们怎么看:我什至认为这是一种官方的坏习惯:对我们之前的人说坏话。
我尝试尽可能多地采取务实的方法:学习代码库,四处逛逛。尝试理解需求和代码之间的关系,甚至根本没有明确的初始关系。当你意识到他们为什么以这种或那种方式做某事时,总会有“啊哈时刻”。如果您仍然确信某些事情是以错误的方式实现的,请尽可能进行重构。并隔离您无法更改的代码片段:使用模拟框架对它们进行单元测试。
向维护开发人员致敬。
我曾经加入过一个团队,该团队被外包给了一堆热气腾腾的废话。最初的项目 - 基于 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 搜索都可以)。将所有文档、电子邮件、代码位置添加到其中。
在开发任何东西之前进行文档分析:找到所有可以在网络上以电子方式获得的东西并打印出文档,努力简单地阅读它。即使在未完成的草稿中,也有许多有用的信息。
随心所欲地对代码、架构等进行思维导图。
由于记录和维护较少的系统,您不可避免地会感到绝望,这可能会使您陷入拖延模式。尤其是在你的第一天或第一周,你的大脑必须消化大量的新信息。在这些时候,很高兴有人提醒你(或自己做)放轻松,首先专注于重要的事情,然后重新采取更小的步骤来试图获得理解,而不是试图向前飞跃。
不断记笔记、制作图表、绘制丰富的图片、思维导图。它确实有助于消化大量的新信息,这些信息大多是杂乱无章的。
嘿,祝你好运!
我们实际上有一组指定的“可交付成果”,我们必须在场才能接管一个项目。
如果我们有机会,我们首先会尝试在开发项目的团队中推动我们的一个人。这样我们就可以在我们的团队接管代码之前获得一些第一手的知识。(在@Guy 写的那一行)
话虽如此,对我来说最重要的部分是:
- 某种代码的高级概述(绘图?)。
- 轻松访问向实际编写代码的人提问
这对我来说是接管代码和项目时的阿尔法欧米茄