5

私は製品に取り組むチームに参加しました。この製品は 5 年ほど前から存在しており、ASP.NET WebForms を使用しています。元のアーキテクチャは時間の経過とともに薄れ、ソリューション全体で物事が比較的混乱しています。それは決してひどいものではありませんが、間違いなくいくつかの作業を使用できます。あなたは皆、私が何を意味するか知っています。

私は約 6 か月前にプロジェクト チームに参加して以来、いくつかのリファクタリングを行ってきました。これらのリファクタリングのいくつかは単純で、Extract Method、Pull Method Up などです。いくつかのリファクタリングはより構造的です。すべてのコンポーネントに付随する単体テストの包括的なスイートがないため、後者の変更は私を不安にさせます。

チーム全体がリファクタリングによる構造変更の必要性を認識していますが、プロジェクト マネージャーは、システムに回帰バグを導入していないという確信を持ってリファクタリングを行うための十分なテストがないという懸念を表明しています。彼は、まず (既存のアーキテクチャに対して) もっと多くのテストを書き、それからリファクタリングを実行することを望んでいます。私の主張は、システムのクラス構造が緊密に結合されすぎて適切なテストを記述できないということです。リファクタリングを実行する際には、よりテスト駆動型のアプローチを使用する方がよいかもしれません。これが意味するのは、既存のコンポーネントに対してテストを書くことではなく、特定の機能要件のテストを作成し、それらの要件を満たすために既存のコードをリファクタリングすることです。

最善の行動方針について経験のある人はいますか? 私自身の考えはありますが、コミュニティからの意見を聞きたいです。

4

5 に答える 5

5

あなたの PM の懸念は有効です。主要なリファクタリングを行う前に、システムをテストするようにしてください。

Michael Feather の著書Working Effectively With Legacy Code ("Legacy Code" Feathers とは、単体テストで十分にカバーされていないシステムを意味します) のコピーを入手することを強くお勧めします。これは、回帰バグを導入するリスクを冒さない安全な方法で、あなたが話している結合と依存関係をどのように分解するかについての良いアイデアがぎっしり詰まっています。

リファクタリング プログラムで頑張ってください。私の経験では、それは多くのことを学べる楽しいカタルシスのプロセスです。

于 2008-08-21T15:38:51.463 に答える
2

並行してリファクタリングできますか? つまり、TDD を使用してリファクタリングする部分を書き直しますが、既存のコード ベースはそのままにしておくということです。次に、新しいテストが PM のニーズを満たしたら、既存のコードを段階的に廃止しますか?

于 2008-08-21T15:37:54.693 に答える
1

また、MartinFowlerによるリファクタリングのWebサイトにアクセスするための提案を提出したいと思います。彼は文字通りこの本を書いた。

方程式に単体テストを導入する限り、私が見つけた最良の方法は、最上位のコンポーネントを見つけて、それが具体的なオブジェクトに持つすべての外部依存関係を特定し、それらをインターフェースに置き換えることです。これを実行すると、コードベースに対して単体テストを作成するのがはるかに簡単になり、一度に1つのコンポーネントで実行できるようになります。さらに良いことに、単体テストを破棄する必要はありません。

ASP.Netの単体テストは難しい場合がありますが、簡単に実行できるフレームワークはたくさんあります。いくつか例を挙げると、 ASP.Net MVC、およびWCSFです。

于 2008-09-17T04:04:27.710 に答える
0

Ian Nelsonからの回答に完全に同意します。さらに、ユーザーの観点から動作を維持するために、いくつかの「高レベル」テスト (機能テストまたはコンポーネント テスト) を開始します。この点は、PM にとって最も重要な関心事かもしれません。

于 2009-01-17T23:29:22.543 に答える
0

レガシーコードを効果的に扱うための2番目の推奨事項を投げかけます。これは、ほとんどすべての古い/くだらない/テスト不可能なコードを扱うことができるという事実に本当に目を向けさせてくれる優れた本です!

于 2008-08-23T11:43:53.027 に答える