問題タブ [legacy]

次のようなレガシー アプリケーションをどのように維持しますか。

1. 単体テストがなく、大きなメソッドがある

2. 多くの重複したロジックがある

3. 関心の分離がない
4. クイックハックとハードコードされた文字列がたくさんあります
5. 古くて間違ったドキュメントがある
6. 要件が適切に文書化されていません! これは実際に、過去にテスター、開発者、およびクライアントの間で論争を引き起こしました. もちろん、遅くしてはならない、クラッシュしてはならない、アプリケーション ユーザーに知られているその他のビジネス ロジックなど、機能以外の要件もいくつかあります。しかし、最も常識的なシナリオと最も常識的なビジネス ワークフローを超えて、何をすべきか (またはすべきでないか) についてのガイダンスはほとんどありません。

???

この従来のマークアップを、構築中の新しいサイトに挿入する必要があります。問題は<embed>タグの使用です。

<embed>フラッシュを持っていない人のために、代替手段として を廃止して、いくつかのコンテンツを入れますか? 基本的には、この html を 21 世紀に持ち込もうとしているだけです。

レガシーシステムの置き換えを進めています。両方のアプリケーションが並行して実行される期間があります。ユーザーはどちらのシステムも使用できますが、課題はデータベースを相互に同期させることです。

新しいシステムは ASP.NET で、レガシーは VB6 です。どちらも SQL Server データベースで実行されています。現時点では、データベースが同じサーバー ルームにあるかどうか、ましてや同じ国にあるかどうかは不明です。

これまでのところ、テーブルにある 2 つのソリューションは次のとおりです。

1. 各マシンに常駐し、他のアプリケーションによって呼び出される Web サービス。
   • ネイティブ オブジェクトの基本クラスの Save メソッドを変更する必要があります。これは侵襲的であり、スイッチをオフにすると問題になる可能性があります.

2. 各データベースをポーリングし、何が変更されたかを調べ、適切な更新を転送する単一の Windows サービス。

   • 両方のアプリケーションのスキーマを変更して、すべてのテーブルに LastModified (DateTime) があることを確認し、任意の間隔で定期的な SELECT を実行できるようにする必要があります。

どちらの解決策も妥当に思えます。どちらのソリューションにも長所と短所があります。ビジネスは、1 つのシステムを更新してから別のシステムで確認するまでの遅延を 2 秒 (!) 以内にするよう求めています。それはおそらくストレッチ ターゲットですが、目指すべきものです。

提案されたが拒否された他のもの（私は再考するつもりです）は次のとおりです。

• データベース トリガー (blogrh)
• BizTalk またはその他のバス (スレッジ ハンマーのように見え、スイッチオーバー ソリューションには複雑すぎる)
• すべてのストアド プロシージャを変更する (nooooo.)
• SSIS (これについてはまだ十分にわかっていません)

あなたが持っているかもしれないどんな考えにも感謝します。

編集: 注意: スキーマは完全に異なります。

.NET3.5sp1でVB6アプリケーションの書き直しに着手しようとしています。VB6アプリは非常によく書かれており、データレイヤーは完全にストアドプロシージャに基づいています。Linq2SQL / Entity Framework / NHibernate/SubSonicのような自動化されたものを使用したいと思います。確かに、私は使い捨てプロジェクト以外でこれらのツールを使用したことはありません。

私がこれらすべての選択で抱えているかもしれない潜在的な問題はスピードです。たとえば、現在、単一の行（またはリスト全体）を取得するには、次のsprocを使用します。

Linq2SQL / Entity Framework / NHibernate / SubSonicで単一の行を取得するには、これらのソリューションでリスト全体をクライアントに表示し、必要な行を見つける必要がありますか？

では、大規模なデータドメインを持つアプリケーションのデータアクセス戦略のコンセンサスは何でしょうか。

顧客が Windows 98 で実行するための小さなツールを作成する必要があります。これは非常に小さなプロジェクトなので、ネイティブの C++ に移行して C# を使用する必要がないように願っています。

.net Framework 2.0のダウンロードは、Windows 98 をサポートしていると主張しています。

私は現在、ロジックとデータ アクセスの両方が GUI クラスに存在するコードで作業しています。もちろん、私はこの状況を改善したいと思っています。

現在の構造は基本的に次のとおりです。

• 泥の大きな玉

最終的な目標は、DDD のような構造を実現することです。

• ダル
• ドメイン モデル
• サービス層
• プレゼンテーション モデル
• GUI

では、どのように問題に取り組みますか?

• ビッグ・バン
  • 最終状態の構造を定義し、コードを最終的なホームにプッシュします。
• 分割統治
  • 泥の大きなボールを 2 つに分けてみてください。完了するまで繰り返します...
• 絞殺
  • クラスを絞め殺します ( http://martinfowler.com/bliki/StranglerApplication.htmlで説明されているように)

単体テストを含まない従来の Web アプリケーションを継承しました。いくつか追加したいのですが、どこから始めればよいかわかりません。それらを古いコードに追加する必要がありますか? それとも新しいコードだけですか？そのコードがレガシー コードとやり取りする場合はどうなるでしょうか。何を提案しますか？

コンパイルされない次のレガシー C++ コードがあります。

GCC (g++) が不平を言う:「'*' トークンの前に初期化子が必要です」

周りを見回すと、次のようにこれらを外部参照として宣言するのがより一般的です。

ポインターが有効ではないのに、参照がこの状況にあるのはなぜですか?

解決：

後述するように、本当の問題は std:: 名前空間指定子が欠落していることです。どうやら、これは古い C++ コードでは一般的でした。

約100の単体テストがあり、カバレッジは％20です。これは、カバレッジを拡大しようとしています。また、これは開発中のプロジェクトなので、新しいテストを追加し続けます。

現在、すべてのビルドの後にテストを実行することは実行可能ではなく、約2秒かかります。

テストに含まれるもの：

• テストフォルダーから読み取られたファイル（一部のHTTPのものをシミュレートするためのデータ駆動型スタイル）
• ローカルWebサーバーへの実際のHTTPリクエストの実行（これはモックするのに非常に苦痛なので、私はしません）
• それらのすべてが単体テストではありませんが、テストする必要のある非常に複雑なマルチスレッドクラスもあり、テストの全体的な動作をテストします。これは機能テストと見なすことができますが、毎回実行する必要があります。

ほとんどの機能には、HTTPの読み取り、TCPの実行などが必要です。これらのテストを変更した場合、プロジェクトの全体像であるため、変更できません。テストを行うのは無意味です。

また、単体テストを実行するための最速のツールはないと思います。私の現在のセットアップでは、フレームワークとしてGallioとnUnitを使用したVSTSを使用しています。VS TS+Gallioも他のものより少し遅いと思います。

この問題を解決するために私に何を勧めますか？少しずつ変更した後に単体テストを実行したいのですが、現在この問題が私の流れを妨げています。

さらなる明確化編集：

コードは高度に結合されています！残念ながら、変更は巨大なrefatoringプロセスのようなものです。そして、そのような大きなコードをリファクタリングするために単体テストが必要な鶏卵症候群がありますが、それをリファクタリングしないと、これ以上単体テストを行うことはできません:)

高度に結合されたコードでは、テストを小さなチャンクに分割することはできません。また、私は個人的なものをテストしません。それは個人的な選択であり、それによって私は非常に速く開発し、それでも大きな利益を得ることができます。

そして、すべての単体テスト（適切な分離を使用）が実際に非常に高速であり、パフォーマンスの問題がないことを確認できます。

さらなる解明：

コードは高度に結合されています！残念ながら、変更は巨大なrefatoringプロセスのようなものです。そして、そのような大きなコードをリファクタリングするために単体テストが必要な鶏卵症候群がありますが、それをリファクタリングしないと、これ以上単体テストを行うことはできません:)

高度に結合されたコードでは、テストを小さなチャンクに分割することはできません。また、私は個人的なものをテストしません。それは個人的な選択であり、それによって私は非常に速く開発し、それでも大きな利益を得ることができます。

そして、すべての単体テスト（適切な分離を使用）が実際に非常に高速であり、パフォーマンスの問題がないことを確認できます。

このレガシ コードを Web アプリに変換する作業を行うたびに、内側が少し死んでいるような気がします。データベースはだめです。すべてのフィールドと列は nvarchar であり、空白 (空の文字列) は、Null を使用して何も意味しない代わりに、何も意味しない (Null) と仮定します。小数を使用する代わりにパーセンテージのようなものを使用します。余分な 2 つのゼロをタグ付けして、文字列 (nvarchar) として保存します。データベースを掘り下げてコードに取り組み、古いレガシー アプリがどのように機能するかを発見します。ちょっと死ぬ。