我希望了解你在接手别人的软件项目时的经验 - 特别是在原软件开发者已经离职的情况下。
5个回答
5
我们在这方面最成功的做法是将所有内容都进行“维基百科化”。在通知期间，请求离职的开发人员帮助你在团队/公司的维基百科中记录所有内容，并尝试与他/她一起进行代码审查，在审查过程中向代码添加注释以解释各个部分。最好由接替者在离职者的监督下编写代码注释。
- Guy
3
原始开发人员在交接项目前离开的情况总是最有趣的：你被困在一个未知状态的代码库中。我总是觉得新开发人员经常尽力评论代码设计有多糟糕：他们忘记了老开发人员可能遇到的限制，他们可能被迫采取的捷径。这句话总是“老开发者==糟糕的开发者”。你们认为呢？我甚至认为这是一种官方的不良做法：诋毁我们之前的人。
我尽可能采用实用主义方法：学习代码库，四处闲逛。试图理解需求和代码之间的关系，即使最初没有明确的关系。总会有“噢”的时刻，当你意识到为什么要以这种或那种方式执行某些操作时。如果你仍然认为某些东西实现方式错误，如果可能的话，请进行重构。并使用模拟框架来隔离您无法更改的代码片段进行单元测试。
向维护开发者致敬。
- ArjanZuidhof
1
老的开发者等于不好的开发者。你说得很对（指一般情绪）。更糟糕的是，新的开发者可能会采取重写软件的方式！！！ - Joel Nat
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％，随着时间的推移变得越来越易于管理，我驯服了这个野兽。
- Manrico Corazzi
1
我在多个场合接手过其他人的代码，质量参差不齐。以下是我的一些建议：
从第一分钟开始努力记录任何重要信息的结构化笔记：利益相关者的姓名、业务规则、代码和文档位置等。最好专门准备一个新的螺旋笔记本，这样如果需要的话就可以撕掉页面。
利用市场上最好的免费索引和桌面搜索工具之一（如Google桌面搜索、MS Windows搜索）。将所有文档、电子邮件、代码位置添加到其中。
在开发任何东西之前进行文档分析：在网络和打印出来的文档中找到您可以获取的所有内容，努力阅读它。即使在未完成的草稿中，也有很多有用的信息。
随着进展，进行代码、架构等思维导图。
对于较少记录和维护的系统，您不可避免地会有绝望的时刻，这可能会让您陷入拖延模式。特别是在您的头几天或一周内，您的大脑必须消化大量新信息的数量令人不知所措。在这些时候，有人提醒您（或自己做）放松心态，集中精力先处理重要事项，并尝试采取更小的步骤来获得理解，而不是试图向前跨越。
继续记录笔记、制作图表、绘制丰富的图片和思维导图。这确实有助于消化大量新信息，大多数情况下是杂乱无章的。
嗨，祝你好运！
- Totophil
0
实际上，我们有一组特定的“可交付成果”，这些成果必须存在才能让我们接手一个项目。
如果有机会，我们会先尝试将我们的人员插入到开发项目的小组中。这样，我们在接管代码之前就可以获得第一手知识。(与@Guy所说的相似)
话虽如此，对我来说最重要的部分是：
- 代码做什么的某种高层次概述(画图?)
- 方便向实际编写代码的人提问
对于我来说，这是接管代码和项目的关键
- svrist
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接