我正在接管一个商业网站的开发。该站点由另一位程序员开发了两年多。这主要是一项单人工作（维护和扩展站点）。当其他程序员向我展示系统时，我将有 2-3 天的过渡期。但据我所知，文档很少。一切都在代码中（有文档记录）。到目前为止，这是我打算问的问题：
还有其他我想念的吗？
[编辑] 谢谢大家。失去好的建议。我希望我能接受多个答案！此外，我还要补充：
最后一件事：开发人员说，如果我需要，他稍后会回答我的问题。毕竟是他的“宝贝”。但我真的认为，在 6 个月内他会继续前进，他的可用性会大大减少！
在看代码之前：
清除 objs 和 exes，让他/她重建东西。注意任何手动交互（它是通过“make”单独构建还是涉及一些摆弄）。
更好的是：给他/她一台裸机（刚买的），让他/她演示结帐并重建。然后看看应用程序是如何启动和出现的（输入的任何秘密选项？）。
然后：在结对编程会话中，向系统添加一个或两个功能，并查看这些功能在何处以及如何实现。
上面的内容可能听起来很愚蠢，但我看到过单独构建是一场噩梦的项目，很多知识只存在于开发人员的大脑中。没有可信的构建环境并且必须弄清楚如何重建是一个噩梦。
请务必询问Web 服务器、域注册商、数据库服务器、电子邮件服务器以及您能想到的任何其他内容的所有登录信息。这听起来很疯狂，但开发人员通常会将自己注册为管理和技术联系人的域名。然后，如果无法联系到原始程序员，公司将不得不与注册商进行各种沟通，以收回域名。
“如果你可以回去重新开发这个系统，你会做些什么不同”
问：a) 关于这个系统，你不想让我问你什么？b) 当你不再从事这个项目时，你最高兴的是什么？c) 系统的哪些部分过于复杂而无法记录？
他的电话。
谁是您的专家用户——我应该寻求或信任谁的意见？
谁是你的危险非专家用户——我应该听谁的，然后主动忽略？
1只有他或她知道
系统要求的周期性“手工工作”是什么？
你知道，那些经常出现但尚未自动化的小工作。您如何修复它以及如何识别它。
询问真正的要求是什么。大多数项目要么没有书面要求，要么没有过时的书面要求。真正的文档通常是口头对话。找出与谁交谈。如果您有来自不同用户的相互冲突的要求，请找出最重要的让您开心的人。
在接管一个项目时，我通常会问的第一个问题是如何让它脱离源代码控制（基本上，“它在哪里？”）。除此之外，我认为你已经达到了所有的高点。
IDE设置、单元测试、部署机制
可能是您可以询问的最重要的事情。
在询问哪些网站影响了您接管的网站时，请确保您获得了链接列表。我发现很多开发人员都会为他们采样的网站保留书签。确保你得到那些。
确保您可以构建和发布它。
缺少信息的问题太多了。
你需要知道所有辅助的东西。
获得一台新机器并确保您可以复制构建和发布。
编辑：在那之后它将是：“你一直想要修复但没有得到并且没有记录在任何地方的所有事情是什么”？
不要问。把他锁在一个房间里——告诉他在他从头开始之前不会得到食物或水，并告诉你他所知道的关于这个系统的一切。然后在相关问题出现时提出相关问题。在此之后 - 花几天时间查看代码。然后重复这个过程。这样做直到您对系统感到满意为止。
确保获得应用程序的所有“陷阱”。它们通常是太小或太古怪而无法拥有正式文档的数据或业务项目，但如果您不知道发生了什么，最终会产生重大影响或大量调试时间。
例如，在我目前维护的一个应用程序中，我们与具有“Web 查看器”类型客户端的第三方系统交互。与此有关的“问题”是 Web 查看器无法正确维护用户的会话状态（在更新到最新版本以修复其他关键问题时损坏）。因此，我不得不时不时提醒用户，把浏览器窗口最小化，这样超时自然会发生，否则他们会被锁定很长一段时间，直到周围的运维人员安装更新版本.
该网站遇到的最大问题是什么以及如何解决？尝试修复一些根本没有意义的东西太容易了，只是发现看似荒谬的东西实际上是一些微妙但令人讨厌的错误的唯一修复。
浏览代码并查看所有看起来难以理解的内容，然后问“这是做什么的，为什么要添加它？”
确保你写下他们的回复——甚至可以在代码中评论他们，以便他们在你需要的时候出现。没有什么比“我知道有人告诉我这件事……”的感觉更令人讨厌了。
以及技术性的东西（这很容易弄清楚:)）了解业务规则！这些很少被正确记录（根据我的经验），并且您通常只会在出现问题时才发现困难的方法。
2 到 3 天的交接时间听起来很短，所以不要害怕要求更多。
首先获得一个可以在本地运行的源代码控制、ide、构建和发布步骤的工作本地环境。
然后尝试通过简要了解代码质量来获得印象。如果它看起来很糟糕，那么您可能不会从您的前任那里获得太多关于实施的有用信息。
但是，应检查有关部署、数据库服务器、备份策略、注册等的所有内容。还有库等的所有许可证以及最常见错误的列表（如果他们有错误跟踪工具，这可能很有用）
此外，您还需要了解您的前任有多大帮助，因为我已经看到了几种移交形式，其中移交的人很友好，但会误导他们以问卷的形式对他们提出的问题做出讽刺性的回答（虽然有趣但不专业）只是不感兴趣。
看代码 5 分钟是最好的开始，如果代码的组织和注释真的很好，可能根本没有任何理由和他交谈。
如果代码很丑陋，那么不要指望他有什么聪明的理由为什么他一起破解了一些东西，充其量你可以用他作为一些肮脏代码的参考并询问目的是什么。
无论哪种方式，与过去的开发人员交谈都是最没用的事情，因为无论哪种方式，你现在都被它困住了。
仔细审查申请并尝试首先弄清楚。然后带着问题进入你的会议，最重要的是，上下文。
你一直在同一家公司工作吗？
如果不是，这与项目没有直接关系，但我会问他为什么要离开。它可能会让您对所涉及的政治有所了解，或者是否有任何事情困扰他与它或与客户一起工作。
询问原始开发人员遇到的任何障碍或解决方法。
同时了解您的客户。他们挑剔吗？他们期待什么？