メンテナンス - いつ変更するかの問題のバランスをとる

Question

私は他の人のためにいくつかのライブラリを管理しています。彼らのそれぞれのためのカップルのリリースを行った後、私は彼らをもう一度やり直す必要があった場合、私は別のやり方があります。

質問は次のとおりです。 私たちはすべて、ジレンマに直面していると思います。メンテナンス活動の有用性と変化の破壊的効果とのバランスをとる方法。

明らかにバグについては、変更が不可欠です。そこにジレンマはありません。 新しい機能については、それはユーティリティと複雑さの問題です。私はその質問に対処するのが楽しいです。

バグ修正と新機能の間のファジースペースです。 1つの例は、フレームワーク設計ガイドラインまたはCLS準拠に準拠するためのメンテナンスです。ある図書館では、CLS準拠を考えずに書いたので、人々はそれを求めました。その結果、私はintを交換するためにインターフェイスを変更しなければなりませんでした。それは（ほとんどの人にとって）少しの利益のために破壊的な変化です。

別の問題：FxCopへの準拠。 FxCopを幸せにするために、いくつかのメソッドのparam名を変更する必要がありました。しかし、これらの変更は実際に反射を使用する人々に影響します。タイプは変更されず、パラメータの名前だけが変更されました。

私が今扱っている問題は、フレームワーク設計ガイドラインです。イベントに関するガイドラインによると、イベントは2つの引数（オブジェクトソース、EventArgs e）で署名する必要があります。しかし、私はFramework Designコースでその日を欠席しました;）。私のライブラリのイベントは現在、EventArgsの引数は1つだけです。

新しいイベントをライブラリに追加しています。 新しいイベントは、フレームワーク設計ガイドラインに従うべきですか？または図書館に既に設置されているパターン？ 新しいイベントのデザインガイドラインを使用する場合は、既存のイベントを変更してデザインガイドラインも遵守する必要がありますか？ もしそうなら、移行を行う方法は？ [Obsolete]属性を使用する必要がありますか？いくつのリリース？

もっと一般的には、バグ修正と新機能の間のこのあいまいな領域のメンテナンスに関する考えに興味があります。

Answer 1

古いコードを変更するのではなく、それを非難してください。適切なデザインで新しいコードを開始し、古いデザインを使用してその部分のコードを書き換えます。最終的には、すべて適切な設計を使用してシステムを完成させることになりますが、それは非常に破壊的な変更ではありません。

Answer 2

変更を加える予定がある場合は、間違いなく多くのことを伝える必要があります。ライブラリをバージョン2として再起動しても、バージョン1は将来バグが修正されるだけで、バージョン2の開発に向かい、新しい機能がすべて見つかるはずです。

しかし、私はこのように行くと思います。バグ修正のためにバージョン1をサポートし、新しいバージョン2を移植して変更を壊す。

Answer 3

私が前に従わなかったいくつかのガイドラインに従おうとすると、私は新しいコードで行います。既存のコードについては、壊れていない限り修正します。しかし、既存のコードにいくつかのバグが見つかった場合は、同時にバグを修正しながらガイドラインを適用することをお勧めします。