2

私は約250,000行のコードであるアプリケーションに取り組んでいます。私は現在、元々.NET1.1で構築されたこのアプリケーションに取り組んでいる唯一の開発者です。全体に浸透しているのは、CollectionBaseから継承するクラスです。すべてのデータベースコレクションは、このクラスを継承します。代わりに、ジェネリックコレクションリストから継承するリファクタリングを検討しています。言うまでもなく、MartinFowlerのリファクタリングの本には提案がありません。このリファクタリングを試みる必要がありますか?もしそうなら、このリファクタリングに取り組むための最良の方法は何ですか?

はい、全体に単体テストがありますが、QAチームはありません。

4

6 に答える 6

2

しないでください。コード ベースをこの演習に使用するビジネス上の正当な理由がある場合を除きます。リファクタリングによって得られるコスト削減または収益はどのくらいですか? 私があなたのマネージャーだったら、おそらく反対するでしょう。ごめん。

于 2008-09-19T00:53:34.297 に答える
2

CollectionBase は継承されたクラスからどのように公開されますか?
Generics が CollectionBase よりも優れている点はありますか?

このクラスは頻繁に使用されますが、1 つのクラスだけです。リファクタリングの鍵は、プログラムの現状を乱さないことです。クラスは常に外部との契約を維持する必要があります。これができれば、リファクタリングするのは 25 万行のコードではなく、おそらく 2500 行だけです (ランダムな推測ですが、このクラスがどれほど大きいかはわかりません)。

しかし、このクラスからの露出が多い場合は、代わりにその露出をコントラクトとして扱い、露出を考慮に入れる必要があります。

于 2008-09-19T04:32:38.687 に答える
2

それをやり遂げる場合は、 List< T >を使用しないでください。代わりに、System.Collections.ObjectModel を使用してください。Collection< T >。これは、CollectionBase の精神的な後継者です。

このCollection<T>クラスは、項目の追加と削除、コレクションのクリア、または既存の項目の値の設定の際の動作をカスタマイズするために使用できる保護されたメソッドを提供します。使用する場合、誰かがコレクションに広告を出したときに処理するメソッドをList<T>オーバーライドする方法はありません。Add()

于 2008-09-19T04:09:47.650 に答える
1

250,000 行はリファクタリングする必要があり、さらに次のいくつかを考慮する必要があります。

  1. リファクタリングされたコードを QA できる QA 部門はありますか?
  2. 古いコードの単体テストはありますか?
  3. ユーザーがバグを見つけたときにコードを保守していますか?

1 番目と 2 番目に「いいえ」と答えた場合は、何よりもまず、既存のコードの単体テストを作成します。それらを広範かつ徹底的にします。それらが整ったら、バージョンを分岐し、リファクタリングを開始します。単体テストは、ジェネリックを正しくリファクタリングするのに役立つはずです。

2 が「はい」の場合は、分岐してリファクタリングを開始し、それらの単体テストに依存します。

QA 部門も同様に大いに役立ちます。テストする新しいコードを提供できるからです。

最後に、クライアント/ユーザーがバグを修正する必要がある場合は、まずそれらを修正します。

于 2008-09-19T00:54:01.910 に答える
1

コードをリファクタリングして最新の状態に保つことは、コードの腐敗や悪臭を避けるための非常に重要なプロセスだと思います。多くの開発者は、自分のコードに固執しているか、単体テストに十分な自信がなく、物事をバラバラにしてクリーンアップし、正しく行うことができないことに苦しんでいます。

時間をかけてクリーンアップしてコードを改善しないと、そのコードを何年にもわたって維持しなければならないため、長期的に後悔するか、コードを引き継ぐ人があなたを嫌うでしょう. 単体テストがあり、それらのテストを信頼して、コードをリファクタリングしても機能することを確認できるはずだとおっしゃいました。

だから私はそれをして、きれいにして、美しくすると言います。単体テストがリファクタリングを処理できるかどうか確信が持てない場合は、もう少し書いてください。

于 2008-09-19T04:05:27.083 に答える
0

私はトーマスに同意します。

リファクタリングを行うときに常に自問すべき質問は、「これを行うことと、他のことをすることで、自分の時間を使って何を得ることができるか」ということだと思います。答えは、保守性の向上からパフォーマンスの向上まで、さまざまですが、常に他の何かが犠牲になります。

コードを見ないとわかりませんが、これはリファクタリングを行うには非常に悪い状況のように思えます。テストは優れていますが、絶対確実というわけではありません。それらの 1 つが間違った前提を持っているだけで、リファクタリングによって厄介なバグが発生する可能性があります。そして、それをキャッチするQAがなければ、それは良くありません.

また、個人的には、このような大規模なリファクタリングについて少し懐疑的です。一度仕事を犠牲にしてください。それは政府の外での私の最初の仕事でした (これはもう少し寛大な傾向があります。「在職期間」を取得すると、解雇されるのは非常に困難です)。私は唯一の Web プログラマーでした。よく書かれていないレガシ ASP アプリを膝の上に落としてしまいました。私の最優先事項は、くそったれなものをリファクタリングして、より厄介なものにすることでした。私の雇用主は火を消すことだけを望んでいました。6 か月後、私は再び仕事を探していました :p この話の教訓: これに着手する前に、まず上司に確認してください。

于 2008-09-19T03:54:48.137 に答える