避免过时代码的敏捷实践？

Question

我正在将一个开放源码的Java库转换为C#，它有许多方法和类被标记为已弃用。这个项目是一个从头开始的机会，所以我计划完全删除它们。然而，作为大型项目的新手，我很担心这种情况会再次出现。由于许多敏捷开发都围绕着现在让某些东西工作，并在需要时进行重构，因此API的弃用似乎肯定是一个常见的问题。即使我不能完全确定项目的未来方向，我是否可以采取预防措施来避免/最小化API弃用？

Answer 1

我不确定你还能做什么。需求会发生变化，如果您必须确保API的客户端不会被较新的API版本破坏，那么您将不得不依赖简单的弃用代码，直到您认为没有人在使用弃用的代码。

在代码上放置过时属性会导致编译器在存在对过时方法的任何引用时创建警告。这样，如果API的客户端努力修复其编译器警告，就可以逐渐迁移到新方法，而不会与新版本断绝关系。

如果你使用ObsoleteAttribute的覆盖，它很有用，它接受一个字符串：

[Obsolete("Foo is deprecated. Use Bar instead for munging widgets.")]

也许你可以创建一个TimeBombAttribute：

[TimeBomb(new DateTime(2010,1,1), "Foo will blow up! Better use Bar, or else."]

在代码中，反映具有timebomb属性的方法，如果在指定日期之后调用这些方法，则抛出KaboomException。这将确保在2010年1月1日之后没有人使用过时的方法，并且您可以很好地清理您的API。:)

Answer 2

正如马特所说，Obsolete属性是您的朋友...但无论何时应用它，都要提供如何更改调用代码的详细信息。这样，你就有了更好的机会让人们真正改变。您可能还想考虑指定您希望在哪个版本中删除该方法(可能是下一个主要版本)。

当然，您应该努力确保不会调用过时的代码-尤其是在示例代码中。

Answer 3

，因为许多敏捷开发都围绕着现在让某些东西工作，并在以后需要时进行重构

这不是敏捷。这是伪装在敏捷标签下的牛仔编码。

理想的情况是，无论你完成了什么，根据你已经完成的任何定义，都是 complete 。通常，DoD会在“特性驱动、测试和相关代码重构”这条线上陈述一些东西。当然，如果你正在开发一个一次性原型，你可以拥有一个更轻松的DoD。

API修改是一件很困难的事情。如果它们只是您正在修改的项目内部API，那么最好的方法就是尽早重构。如果您需要更改内部API，只需继续并同时更改所有API客户端。这样，重构的债务就不会变得很大，你也不必使用弃用。

对于已发布的API，您可能需要维护一些源代码和二进制兼容性保证，至少在下一个主要发行版发布之前是这样。在保持兼容性的同时，将旧的API标记为不推荐使用。与内部API一样，您应该尽快修复您的内部代码，以避免使用不推荐使用的API。