内部api开发和提交过程

Question

我现在正在扩展和重构大多数其他组件所依赖的一组API和核心数据结构。这个队很小(5人)。

一位经理告诉我，在签入更改之前，我应该搜索整个代码库，找出所有依赖于我更改的API的函数，并在必要时对它们进行修改，以确保整个软件工作正常。我对这个请求感到有点吃惊。

在程序方面，我认为我应该做的就是测试我自己的东西，文档，并为其他人提供相应的更新指导。更糟糕的是，我知道单元测试并没有对某些组件进行彻底的测试。我怎么可能确定我的更改不会在其他人的组件中创建bug呢？而且发展是积极的，几乎可以肯定的是，我为别人推动的变革会在任何地方制造局部冲突。

在拒绝这一请求之前，是否有人能为这一请求提供其他观点？内部API更新的常见做法是什么？谢谢。

Answer 1

听起来，经理最关心的是确保软件始终处于存储库中的工作状态。这不是一个不合理的请求，因为他们可以在任何时候提取并编译它以供发布，而且他们希望确信他们没有发布一个糟糕的构建。

你的经理提出了一个方案，但这个选项有你提到的问题。您必须在整个代码库中搜索对API的调用(这可能不是100%可靠的)。您必须编辑其他团队正在积极开发的代码，这会导致冲突和人际冲突的合并。您将尝试重构您可能不完全理解的代码(并且没有测试的支持)。这种方法会导致..。挑战。

还有其他选择。例如，将旧API重构为新API的适配器可能是有意义的。这样，新代码在内部被调用，而在外部，不需要立即更改他们的代码。随着时间的推移，您可以通过与其他开发人员(而不是与他们周围的开发人员)一起工作来进行转换，同时保持代码的完全功能。

这样做的一个好处是，您可以在旧API调用中添加日志记录，以了解这些调用是从哪里发出的，以及调用的频率。通过这种方式，您可以优先考虑某些需要转换的区域，而不必立即更改所有内容。

这一战略不可能没有挑战。例如，两个API之间可能存在命名冲突。为您的API开发一个版本控制方案将有所帮助，并将在未来缓解这个问题。您需要支持这两个API一段时间。由于旧API将简单地包装新API，所以更改应该主要落在新API上。您可能不得不破解不兼容(不推荐的数据结构等)。这是正常的过程，但它将把这个问题限制在你直接控制的一个地方。

Answer 2

我的诀窍是确保编译器为您分配工作。

我将一个方法或类标记为[Obsolete]，以查找它所使用的所有位置，或者只使用find函数。[Obsolete]方法更好，因为这将在编译时通知使用者已经提供了一种替代技术。

绘制API类和结构的图表，以便您可以识别自包含的功能、辅助函数、公共主题和依赖项。如果可能的话，记录使用者使用的类，看看有多少API类/字段/事件可以是私有的或内部的，而不会损害使用者。您需要维护的公共界面越小，您在返工过程中就越灵活。

作为第一步，创建公共接口并将它们添加到API中也是很有帮助的，随后，您需要对该接口所做的任何更改都将反映在编译器错误中，您可以很容易地使用find所有引用或类似的方法找到使用者。

寻找内置在API中的扩展点并利用它们，不要重新发明轮子或重构大部分代码。尽量使用已经存在的代码。

如果您使用Visual 试试微软的这个加载项。，它可以帮助您在一个可能需要寻址的代码基中找到角落案例，并实现System.Diagnostics.Contracts，这可以帮助您找到属于这些角落情况的代码。

尝试将API的许多关键使用者包括在API的构建中，这样虽然编译将花费更长的时间，但在编译时会通知您库更改中出现的任何问题。