维护 - 平衡何时以及是否进行更改的问题

Question

我为其他人维护了几个图书馆。在为每个人发布了几个版本后，我会做一些不同的事情，如果我不得不再做一遍。

问题是：我应该完成它们吗？ 我想我们都面临着这样的困境 - 如何平衡维护活动的有用性与变化的破坏性影响。

显然，对于错误，这种变化势在必行。没有困境。 对于新功能，这是一个实用性与增加复杂性的问题。我很乐意处理这个问题。

我正在询问错误修正和新功能之间的模糊空间。一个例子是维护以符合框架设计指南或CLS合规性。对于一个图书馆，我在没有考虑CLS合规性的情况下编写了它，然后人们要求它。因此，我不得不修改接口以交换uint为int。这是一次破坏性的改变，对于大多数人来说收效甚微。

另一个问题：FxCop合规性。我必须对某些方法的param名称进行更改，以使FxCop满意。但这些变化实际上只影响使用反射的人 - 类型没有改变，只有参数的名称。

我现在正在处理的问题是：框架设计指南。关于事件的指南说事件应该有一个带有两个参数的签名:( Object source，EventArgs e）。但是那天我在框架设计课程中缺席了;）。我库中的事件目前只占用一个EventArgs参数。

我现在正在向库中添加新事件。 新活动是否应遵循框架设计指南？或图书馆已经建立的模式？ 如果我使用新事件的设计指南，我是否应该修改现有事件以符合设计指南？ 如果是这样，如何进行迁移？我应该使用[Obsolete]属性吗？有多少个版本？

更一般地说，我对在bugfix和新功能之间的模糊区域中的维护感兴趣。

Answer 1

而不是修改旧代码弃用它。使用适当的设计启动新代码，并使用旧设计为部件编写替换代码。最终你会得到一个使用正确设计的系统，但它不会是一个非常具有破坏性的变化。

Answer 2

如果您计划进行重大更改，您肯定需要进行大量沟通。即使您将作为版本2重新启动库，您也必须告诉您的用户将来只会修复版本1，并且您将前往版本2开发，他们可以找到所有新功能。

但我认为我会这样做。支持版本1的错误修正，并为新版本2提供重大修改。

Answer 3

如果我尝试遵循之前没有遵循的一些指导原则，我会在新代码中执行。对于现有代码，我将修复它们，除非它们被破坏。但是，如果您在现有代码中发现了一些错误，那么在修复错误的同时应用指南是一种很好的做法。