接pipe一个项目 – 我应该问以前的程序员？
我正在接pipe一个商业网站的开发。 这个网站是由另一个程序员两年来开发的。 这主要是一个人的工作（维护和扩大网站）。 当另外一个程序员给我看系统的时候，我会有一个2-3天的过渡期。 但是从我所知道的是，没有什么文件。 一切都在代码中（这是有记载的）。 这是我到目前为止要问的问题：
- 系统中最复杂的元素的解释
- 整体build筑的描述
- 支持工具的说明（IDE设置，unit testing，部署机制）
- 他用来影响系统架构的任何书籍，网站，播客
任何其他我失踪？
[编辑]谢谢大家。 失去了好的命题。 我希望我能接受不止一个答案！ 另外，我还要补充：
- 你有什么特别的做法来提高系统的性能，现在瓶颈在哪里？
- 与此相关的是，你在系统的安全性方面做了些什么？ （你做了什么，现在安全漏洞在哪里）
最后一件事是：开发者说如果我需要的话，他会在稍后回答我的问题。 毕竟这是他的“宝贝”。 但是我真的认为在6个月内他将会继续前进，他的可用性将会大大降低！
请务必要求提供所有Web服务器，域名注册商，数据库服务器，电子邮件服务器以及您能想到的任何其他login信息 。 这听起来很疯狂，但是开发者通常会把自己的域名注册为pipe理和技术联系人。 如果原先的程序员无法联系，公司将不得不跳过与注册服务商的各种环节，以获得域名。
在你看代码之前：
清除这些东西和东西，让他/她重build这个东西。 注意任何手动交互（它是通过“make”单独构build的还是涉及到一些小问题）。
更好的是：给他/她一个赤裸的（刚买的）机器，让他/她展示一个结帐和重build。 然后看看应用程序是如何启动和启动（任何秘密选项input？）。
然后：在一对编程会话中，向系统中添加一个或两个function，并查看在哪里以及如何实现这些function。
上面这些听起来很愚蠢，但是我看到单独build设的项目是一场噩梦，只有开发人员的大脑里有很多知识。 没有一个可靠的构build环境，不得不弄清楚如何重build是一个nighmare。
“如果你能回去重build这个系统，你会做什么不同的事情”
问：a）你不想问我关于这个系统的问题吗？ b）当你不再从事这个项目时，你最高兴的是什么？ c）系统的哪些部分太复杂，无法logging？
他的电话。
谁是你的专家用户 – 我应该寻求或信任谁的意见？
谁是你非常危险的非专家用户 – 我应该听谁，然后主动忽略？
系统需要什么样的定期“手工作业”？
你知道，那些经常出现的小工作还没有自动化。 你如何解决这个问题，你如何认识它。
问什么是真正的要求。 大多数项目要么没有书面要求，要么没有过时的书面要求。 真正的文档通常是口头对话。 找出与谁交谈。 如果您对不同用户的要求有冲突，请找出最重要的是要让他们开心。
- 已知1个问题
- 已知1个方面的改进
- 现有的代码覆盖率数据，testing合格率等作为基准
- 疑难解答提示（了解日志文件，debugging崩溃，常见陷阱）
- configuration参数说明
1只知道他或她
在接pipe项目时，我通常会问的第一个问题是如何从源代码pipe理中解脱出来（基本上是“它在哪里？”）。 除此之外，我认为你已经达到了所有的高点。
IDE设置，unit testing，部署机制
可能是你可以问的最重要的事情。
当询问哪些网站影响了您接pipe的网站时，请确保您获得链接列表。 我发现很多开发人员将书签保存到他们抽样的网站上。 确保你得到这些。
确保您可以构build和发布IT。
信息丢失的次数太多了。
你需要知道所有的辅助的东西。
得到一个新的机器，并确保您可以复制构build和发布。
编辑：在那之后它会是：“你有什么意思修理，但没有得到，没有logging在任何地方”？
不要问。 把他锁在一个房间里 – 告诉他，一开始他就不会得到食物或水，并告诉你他所知道的关于这个系统的一切。 然后问他们出现的相关问题。 之后 – 花两天时间查看代码。 然后重复这个过程。 这样做，直到你感觉舒适的系统。
- 你将如何在一个全新的服务器上安装网站。
- 网站的function和用途
- 使用哪些数据库以及它们在哪里
确保获得应用程序的所有“陷阱”。 他们往往是数据或业务项目是太分钟或古怪有正式的文件，但结束了很大的影响或debugging时间很多，如果你不知道发生了什么事情。
例如，在我目前维护的一个应用程序中，我们与具有“web查看器”types客户端的第三方系统进行交互。 与此相关的“陷阱”是，Web查看器没有正确地维护用户的会话状态（在更新到最新版本以解决其他关键问题时中断）。 因此，我不得不经常提醒用户，尽量减less浏览器窗口，以便超时自然发生，否则会长时间被locking，直到这里的OPS人员安装新版本。
网站遇到的最大的问题是什么以及如何解决？ 尝试修复一些根本没有意义的事情太容易了，只是发现看起来没有什么意义的东西实际上是对一些微妙但讨厌的错误的唯一修复。
仔细阅读代码，看看所有看起来很难理解的东西，只是问“这是干什么的，为什么要加上它？”
确保你写下他们的回应 – 甚至可以在代码中评论他们，所以当你需要他们的时候他们就在那里。 除了那种“我知道我被告知这个……”的感觉之外，没有比这更令人讨厌的了。
以及技术的东西（这是“容易”弄清楚:)）了解业务规则！ 这些很lesslogging在案（以我的经验），而且通常只有在出现问题时才能find困难的方法。
2至3天听起来很短的交接，所以不要害怕要求更多。
首先通过源代码pipe理，IDE，构build和发布步骤来获得本地运行的本地环境。
然后尝试通过简短的介绍来获得代码质量的印象。 如果看起来不好，那么你可能没有得到有关你的前任的实施的有用的信息。
然而，应该检查有关部署，数据库服务器，备份策略，注册等的一切。 也是所有图书馆的许可证，也是最常见的错误列表（如果他们有一个错误跟踪工具，这可能是有用的）
你也需要看看你的前任是多么有帮助，因为我已经看到了几种交接forms，他们给予交接的人友好但误导他们以问答的forms对他们提出的问题作出讥讽的回答这有趣而不是专业），只是无私的。
查看5分钟的代码是最好的开始，如果代码组织得很好，评论可能没有任何理由与他交谈。
如果代码是可怕的，那么不要指望他有什么聪明的理由为什么他们一起黑客攻击，至多你可以用他作为参考一些cruddy代码，并问是什么目的。
无论哪种方式，与过去的开发人员交谈是最不有用的事情，因为无论哪种方式，你现在都陷入困境。
仔细检查应用程序，并尝试找出第一。 然后带着问题进入你的会议，最重要的是上下文 。
你在同一家公司工作过吗？
如果没有，这与项目没有直接关系，但我会问他为什么要离开。 这可能会让你对所涉及的政治有所了解，或者是否有什么困扰他与之合作或与客户合作。
询问原始开发者遇到的任何障碍或变通方法。
了解您的客户以及。 他们挑剔吗？ 他们期望什么？
