遗留代码移交最佳实践
几个月后，一位同事将继续进行一个新项目，而我将继承他的一个项目。为了准备，我已经下令迈克尔·费瑟斯（Michael Feathers）有效地使用旧版代码。 但是本书以及到目前为止我发现的有关遗留代码的大多数问题都与按原样继承代码的情况有关。但是在这种情况下，我实际上可以访问原始开发人员，并且我们确实有时间进行有序移交。 我将继承的一段代码背景： 它的功能是：没有已知的错误，但是随着性能要求的不断提高，在不久的将来将需要进行一些优化。 未记录：在方法和类级别上几乎有零个文档。但是，该代码应该在更高级别上执行的操作已被很好地理解，因为多年来我一直在使用其API（作为黑匣子）进行编写。 只有更高级别的集成测试：只有集成测试可以测试通过API与其他组件之间的正确交互（再次是黑匣子）。 非常低级的，针对速度进行了优化：由于此代码是整个应用程序系统的核心，因此多年来，许多代码已进行了多次优化，并且非常低级（对于某些结构，一部分具有自己的内存管理器） /记录）。 并发和无锁：虽然我对并发和无锁编程非常熟悉，并且实际上为该代码贡献了一些内容，但这又增加了另一层复杂性。 大型代码库：这个特定的项目有超过一万行代码，因此我无法向我解释所有内容。 用Delphi撰写：尽管我不认为该语言与该问题紧密相关，但我将把它放在这里，因为我认为这种类型的问题与语言无关。 我想知道如何才能最好地度过他离开之前的时间。这里有一些想法： 让一切都可以在我的机器上构建：尽管应该将所有内容检查到源代码控制中，但谁也不会忘记偶尔检查一次文件，因此这应该是首要任务。 更多测试：虽然我希望进行更多的类级单元测试，以便在进行更改时可以尽早发现我引入的任何错误，但现在的代码不可测试（大型类，长方法，太多代码）相互依赖）。 文档内容：我认为对于初学者来说，最好将文档重点放在代码中那些本来就难以理解的领域，例如由于其低级/高度优化的特性。恐怕其中有些事情看起来很丑陋，需要重构/重写，但是实际上其中存在一些优化，这是我可能会错过的一个很好的原因（参见Joel Spolsky，您应该做的事情）从不做，第一部分） 如何记录：我认为最好是一些体系结构的类图和关键功能的序列图以及一些散文。 向谁记录：我想知道让他写文档或让他向我解释会更好，这样我可以写文档。我担心，对他而言显而易见但对我而言不明显的事情将无法得到适当覆盖。 使用成对编程进行重构：由于时间限制，这可能无法实现，但是也许我可以重构他的一些代码，以使其在他仍然在提供有关事物为何如此的方式的输入时更加可维护。 请评论并添加到此。由于没有足够的时间来完成所有这些工作，因此我对如何确定优先级特别感兴趣。 更新：移交项目结束后，我在下面的答案中根据自己的经验扩展了此列表。