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

【问题标题】：Maintenance - balancing the question of when and if to make changes维护 - 平衡何时以及是否进行更改的问题
【发布时间】：2009-03-05 18:14:56
【问题描述】：

我为其他人维护了几个库。在为他们每个人完成了几个版本之后，如果我不得不重新做一些事情，我会做一些不同的事情。

问题是：我应该重做吗？我想我们都面临这样的困境——如何平衡维护活动的帮助与变革的破坏性影响。

显然，对于错误，更改势在必行。那里没有两难境地。对于新功能，这是实用性与增加复杂性的问题。我觉得处理这个问题很舒服。

我要问的是错误修复和新功能之间的模糊空间。一个例子是维护以符合框架设计指南或 CLS 合规性。对于一个图书馆，我写它时没有考虑 CLS 合规性，然后人们要求它。结果，我不得不修改接口以将 uint 换成 int。这是一个破坏性的变化，收益微乎其微（对大多数人来说）。

另一个问题：FxCop 合规性。为了让 FxCop 高兴，我不得不更改某些方法的参数名称。但是这些变化实际上只影响使用反射的人——类型没有改变，只有参数的名称。

我现在处理的问题是：框架设计指南。关于事件的指南说事件应该有一个带有两个参数的签名：（对象源，EventArgs e）。但是那天我没有参加我的框架设计课程；）。我的库中的事件目前只需要一个 EventArgs 参数。

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

更一般地说，我对在错误修复和新功能之间的这个模糊区域进行维护的想法很感兴趣。

【问题讨论】：

【解决方案1】：

与其修改旧代码，不如弃用它。以正确的设计开始您的新代码，并为使用旧设计的部分编写替换代码。最终你会得到一个全部使用正确设计的系统，但这不会是一个非常具有破坏性的改变。

【讨论】：

【解决方案2】：

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

但我想我会走这条路。支持版本 1 进行错误修复并移植新版本 2 以进行重大更改。

【讨论】：

【解决方案3】：

如果我尝试遵循一些我以前没有遵循的准则，我会在新代码中这样做。对于现有代码，我会修复它们，除非它们被破坏。但是，如果您在现有代码中发现了一些错误，最好在修复错误的同时应用这些准则。

【讨论】：