接管一个项目 - 我应该问以前的程序员？

Question

我正在接管商业网站的开发。该网站由另一位程序员开发了两年多。这主要是一个人的工作（维护和扩展网站）。当其他程序员向我展示系统时，我将有2-3天的过渡期。但据我所知，文件很少。一切都在代码中（这是一种记录）。以下是我计划到目前为止所要求的内容：

• 关于系统中最复杂元素的说明
• 整体架构说明
• 支持工具的说明（IDE设置，单元测试，部署 机构）
• 他用来影响网站架构的任何书籍，网站，播客 系统

我还缺少任何其他人吗？

[编辑]谢谢大家。失去了好的主张。我希望我能接受不止一个答案！另外，我还要补充：

• 您有什么专门为提高系统性能而做的，现在瓶颈在哪里？
• 与此相关，您对系统的安全性做了什么？ （你做了什么，现在安全漏洞在哪里）

最后一件事：开发人员表示，如果我需要，他可以在以后回答我的问题。毕竟这是他的“宝贝”。但我真的认为在6个月内他会继续前进，他的可用性将会大大减少！

Answer 1

在你看代码之前：

清除objs和exes，让他/她重建这件事。 注意任何手动交互（它是通过“make”单独构建还是涉及到一些小问题。）

更好的是：给他/她一台裸露的（刚购买的）机器，让他/她展示一个结账并重建。然后看看应用程序是如何启动和启动的（输入的任何秘密选项？）。

然后：在一对编程会话中，向系统添加一个或两个功能，并查看这些功能的实现位置和方式。

以上可能听起来很愚蠢，但我看到过单独建造是一场噩梦的项目，而且很多知识只在开发人员的大脑中。没有可信赖的构建环境并且不得不弄清楚如何重建是一个蠢事。

Answer 2

请务必询问网络服务器，域名注册商，数据库服务器，电子邮件服务器以及您能想到的任何其他内容的登录信息。这听起来很疯狂，但开发人员通常会将自己的域名注册为管理和技术联系人。如果无法联系原始程序员，公司将不得不通过注册商跳过各种箍，以便恢复域名。

Answer 3

“如果你可以回去重新开发这个系统，你会做什么不同的事情”

Answer 4

问：a）你不想让我问你这个系统有什么问题？ b）当你不再从事这个项目时，你最开心的是什么？ c）系统中哪些部分过于复杂而无法记录？

Answer 5

他的电话。

Answer 6

谁是您的专家用户 - 我应该寻求或信任他的意见？

谁是您危险的非专家用户 - 我应该听谁，然后积极忽略？

Answer 7

• 已知 ¹ 问题
• 已知的 ¹ 改进领域
• 现有代码覆盖率数据，测试合格率等将用作基线
• 故障排除提示（了解日志文件，调试崩溃，常见问题）
• 配置参数说明

¹ 只知道他或她

Answer 8

系统需要的定期“手工作业”是什么？

你知道，那些经常出现但尚未实现自动化的小工作。你如何解决它，你如何识别它。

Answer 9

询问真实的要求是什么。大多数项目要么没有书面要求，要么没有过时的书面要求。真正的文档通常是口头对话。找出与谁交谈的人。如果您的不同用户的要求存在冲突，请找出最重要的人才。

Answer 10

我接管项目时通常会问的第一个问题是如何将其从源代码控制中解决（基本上，“它在哪里？”）。除此之外，我认为你已经达到了所有的高点。

  

IDE设置，单元测试，部署机制

可能是你可以提出的最重要的事情。

当询问哪些网站影响了您正在接管的网站时，请确保获得链接列表。我发现很多开发人员都会将书签保存到他们从中采样的网站。确保你得到那些。

Answer 11

确保您可以构建并发布它。

太多次信息丢失都有问题。

你需要了解所有辅助材料。

获取一台新机器并确保您可以复制构建和发布。

编辑： 在那之后它会是：“你有什么意思要修复但没有到达并且没有记录在任何地方”？

Answer 12

• 如何在全新的服务器上安装该网站。
• 网站的作用＆amp;它用于什么。
• 使用了哪些数据库＆amp;他们在哪里。

Answer 13

2到3天听起来很短暂，所以不要害怕要求更多。

首先获得一个有效的本地环境，其源代码控制，ide，构建和发布步骤都在本地运行。

然后通过简要介绍来尝试获得代码质量的印象。如果它看起来很糟糕，那么您可能无法获得有关前任实施的有用信息。

但是，应检查有关部署，数据库服务器，备份策略，注册等的所有内容。还有库等的所有许可证以及最常见的错误列表（如果他们有错误跟踪器工具，这可能很有用）

你还需要看看你的前任是多么有帮助，因为我看到了几种交接形式，其中交接的人是友好的，但误导他们以一种形式对他们提出的问题作出讽刺性回答。一个问卷（虽然有趣但不专业）只是简单无私。

Answer 14

除了技术性的东西（这很容易弄明白:) :)了解业务规则！这些很少被正确记录（根据我的经验），你通常只会在出现问题时找出困难的方法。

Answer 15

该网站遇到的最大问题是什么以及它们是如何解决的？尝试修复一些根本没有意义的东西太容易了，只是发现看似荒谬的东西实际上是解决一些微妙但令人讨厌的bug的唯一方法。

仔细阅读代码并查看任何难以理解的内容，只询问“这是做什么的，为什么要添加它？”

确保记下他们的回复 - 甚至可以在代码中对它们进行评论，以便在您需要时将它们存在。没有什么比“我知道我被告知这个......”的感觉更令人烦恼。

Answer 16

确保获得该应用程序的所有“陷阱”。它们通常是数据或业务项目，如果您不知道发生了什么，那么它们过于微小或古怪而无法获得正式文档，但如果您不知道发生了什么，最终会产生巨大的影响或大量的调试时间。

例如，在我目前维护的一个应用程序中，我们与具有“web查看器”类型客户端的第三方系统连接。与此相关的“问题”是Web查看器无法正确维护用户的会话状态（当它更新到最新版本以解决其他关键问题时会中断）。因此，我必须不时地提醒用户简单地最小化浏览器窗口，以便自然地发生超时，否则它们将被锁定很长一段时间，直到这里的Ops人员安装了更新的版本

Answer 17

不要问。将他锁在一个房间里 - 告诉他在开始之前他不会得到食物或水，并告诉你他对系统的所有了解。然后在问题出现时询问相关问题。在此之后 - 花几天时间查看代码。然后重复这个过程。这样做直到您对系统感到满意为止。

Answer 18

仔细检查应用程序并尝试先弄清楚。然后使用问题进行会议，最重要的是上下文。

Answer 19

查看代码5分钟是最好的开始，如果代码组织得很好并且评论完毕，可能没有任何理由与他交谈。

如果代码是可怕的，那么不要指望他为什么一起攻击某些东西的任何明智的理由，充其量你可以使用他作为一些肮脏代码的参考，并询问目的是什么。

无论哪种方式，与过去的开发人员交谈是最不实用的事情，因为无论哪种方式，你现在都坚持使用它。

Answer 20

你在同一家公司工作过吗？ 如果没有，这与项目没有直接关系，但我会问他为什么要离开。它可能会让您对所涉及的政治有所了解，或者是否有任何事情困扰着他与之合作或与客户合作。

Answer 21

询问原始开发者遇到的任何障碍或解决方法。

了解您的客户。他们挑剔吗？他们期待什么？