1

私たちのチームには、さらなるメンテナンスと開発のためのレガシーシステムが与えられています。これは真の「レガシー」なものであるため、テストの数は非常に少なく、ほとんどががらくたです。これはWebインターフェースを備えたアプリであるため、コンテナー管理コンポーネントと、必要に応じていちこちで「新しく」なプレーンJavaクラス（フレームワークなどに関連付けられていない）の両方があります。

このシステムで作業するとき、特定の部分に触れるたびに、すべてのものを小さな断片に分割し、依存関係を検出してリファクタリングし、依存関係をコードにプルするのではなくプッシュしようとします。

私の質問は、そのようなシステムをどのように操作するか、依存関係を破る方法、コードをよりテストしやすくする方法などです。いつ停止し、これにどのように対処するのですか？

例を示しましょう：

public class BillingSettingsAction {

    private TelSystemConfigurator configurator;
    private OperatorIdDao dao;

    public BillingSettingsAction(String zoneId) {
        configurator = TelSystemConfiguratorFactory.instance().getConfigurator(zoneId);
        dao = IdDaoFactory.getDao();
        ...
    }

    // methods using configurator and dao
}

このコンストラクターは間違いなくやりすぎです。また、これをさらにリファクタリングするためにテストするには、PowerMockなどで魔法をかける必要があります。私が行うことは、次のように変更することです。

public BillingSettingsAction(String zone, TelSystemConfigurator configurator, OperatorIdDao dao) {
    this.configurator = configurator;
    this.dao = dao;
    this.zone = zone;
}

または、依存関係のセッターのみをコンストラクター設定ゾーンに提供します。

私が見ている問題は、コンストラクターで依存関係を提供する場合でも、どこかに依存関係を提供する必要があるということです。つまり、問題を1レベル上に移動しているだけです。すべての依存関係を配線するためのファクトリを作成できることは知っていますが、アプリのさまざまな部分に触れると、それぞれに異なるファクトリが発生します。明らかに、すべてのアプリを一度にリファクタリングして、Springなどを紹介することはできません。

セッターの公開（おそらくデフォルトの実装が提供されている）も同様であり、さらにテスト専用のコードを追加するようなものです。

だから私の質問はあなたがそれをどのように扱うかです？オブジェクト間の依存関係を一度に実行せずに、より良く、より読みやすく、テスト可能にする方法は？

4

2 に答える 2

3

私は最近、MichaelFeathersによる「レガシーコードを効果的に使用する」を読み始めました。この本は基本的にあなたの質問に対する答えです。これは、レガシーシステムを段階的にテストし、コードベースを段階的に改善するための非常に実用的な「ナゲット」と手法を示しています。

この本は、ほぼ1ページから特定のテクニックを指し示しているため、ナビゲーションは少し混乱する可能性がありますが、これまでのところ、コンテンツは非常に有用であることがわかりました。

私は著者などとは関係がありません。同じような状況に直面していて、これが非常に興味深いリソースであることがわかっただけです。

HTH

于 2012-04-16T21:29:45.587 に答える
2

私はボーイスカウトルールのようなルールを確立しようとします。ファイルに触れるときはいつでも、実装したいものを実装することは別として、ファイルを少し改善する必要があります。

あなたができることをサポートするために

  • 2時間の機能作業の場合、1時間のクリーンアップを許可するなど、このような改善のための固定時間予算に同意します。

  • 時間の経過に伴う改善を示す指標を表示します。多くの場合、平均ファイルサイズやテストカバレッジなどの単純なもので十分です。

  • 少なくとも大きなもののために変更したいもののリストを用意します。たとえば、「TelSystemConfiguratorFactoryを取り除く」トラックでは、すでに作業しているタスクを追跡し、新しいものからすでに開始したものに取り組むことを好みます。

いずれにせよ、経営陣があなたのアプローチに同意することを確認してください。

より技術的な側面：あなたが示したアプローチは良いです。多くの場合、すべての依存関係を提供する2番目のコンストラクターを検討しますが、パラメーターを使用した新しいコンストラクターを使用します。追加のコンストラクターを非推奨にします。そのクラスのクライアントに触れるときは、新しいコンストラクターを使用するようにします。

Spring（または他のDIフレームワーク）を使用している場合は、静的ファクトリへの呼び出しを、Springを介して実際に作成し、すべての依存関係を注入する前に、中間ステップとしてSpringコンテキストからインスタンスを取得することから始めることができます。

于 2012-04-16T19:27:05.307 に答える