問題タブ [legacy]

SQL2005に挿入するVisualFoxproデータベースからいくつかのレガシーデータを読み取るVBを使用してWindowsサービスを作成しました。問題は、この使用法がWindows Server 2003 32ビットで正常に実行されることですが、クライアントは最近Windows200364ビットに移行しました。そして今、サービスは機能しません。VFP.NETOLEdbプロバイダーが見つからないというメッセージが表示されます。私が調べたところ、解決策がないことがすべて指摘されているようです。助けてください...

最近、すべてのコードに単体テストがあるわけではない古いシステムで、いくつかのコードを変更する必要がありました。
変更を加える前にテストを書きたいのですが、各クラスは多くの依存関係やその他のアンチパターンを作成し、テストが非常に困難でした。
明らかに、コードをリファクタリングして、テスト、テストの作成、および変更を容易にしたかったのです。
これがあなたのやり方ですか？それとも、リファクタリングが完了した後にほとんど削除される、書きにくいテストの作成に多くの時間を費やしますか?

このような一般的な質問をしたことをお詫びしますが、それは私にとってやりがいのあることです。私のチームは、何年にもわたって進化してきたランダムな1回限りのコードベースをすべてまとめる大規模なプロジェクトに着手しようとしています。このプロジェクトは、会社全体の論理エンティティ（「顧客」、「従業員」）、小さなタスク、小さなタスクを制御する大きなタスク、およびユーティリティサービスを対象としているため、構造化するための最良の方法を見つけるのに苦労しています。名前空間とコード構造。

先に進むのに十分な詳細を提供していないと思いますが、ドメインを論理的に分割する方法についてのリソースやアドバイスはありますか？役立つ場合は、この機能のほとんどがWebサービスを介して公開されます。私たちは、最新のギズモとガジェットをすべて備えたMicrosoftショップです。

• 参照を簡単にするためにサブプロジェクトを使用した1つの大規模なソリューションについて議論していますが、それでは扱いにくくなりますか？
• レガシーアプリケーションの機能をまとめる必要がありますか、それとも名前空間に完全に依存しないままにする必要がありますか（たとえば、OurCRMProduct.Customerクラスとジェネリッククラスの作成）？Customer
• 各サービス/プロジェクトには独自のBALとDALが必要ですか、それともすべてが参照する完全に別個のアセンブリである必要がありますか？

私はそのような広範囲にわたるプロジェクトを組織した経験がなく、1回限りのことなので、私が得ることができるガイダンスを探しています。

仮想化されたデスクトップ PC (WinXP Pro 以前を実行) を使用して、めったに使用されない古いアプリケーションをいくつかの進行中のタスクに使用できるようにする人がいるかどうか疑問に思いました。

データベース システムなどで時々ドキュメントの更新が必要な、非常に古いプロジェクトがあるとします。データベース アプリケーションは、必要なときにのみ起動される仮想化されたデスクトップ上で実行されます。

これらの古いボックスの一部を仮想化すれば、エネルギー、ハードウェア、およびスペースを節約できると思います。あなたの会社の設定はありますか？

editライセンスが問題になる可能性がありますが、古いデスクトップ ボックスの有効なライセンスを持っていると思います。ライセンスが VM 環境で有効でない可能性があります。事前に確認しておきましょう。

案の定、アプリケーションがパフォーマンスを重視する場合、仮想化は害を及ぼす可能性があります。しかし、特定の顧客/サービスに対して12週間ごとに計算するなど、まだ実行に使用されているある種の時代遅れのアプリケーションについて考えています。

レガシー アプリケーションでのサインオンを減らすために人々がどのような戦略を使用し、それらがどの程度効果的であるかを知りたいのですが?

私たちは ASP.Net ベースのイントラネットを所有しており、多くのレガシー アプリケーションを所有していますが、すべてではありません。また、BizTalk もあり、その SSO エンジンも使用することを検討しています。

現在、いくつかの新しいプロジェクトを追加し、いくつかの古いリポジトリからのレガシー コードとデータをマージして、ローカルの Subversion リポジトリを再構築中です。

過去にこれを行ったときは、通常、新しい「適切に構造化された」コードツリーを「邪魔」しないように、レガシーコードを専用の「レガシー」フォルダーに入れました。しかし、リファクタリングの精神からすると、これは少し間違っていると思います。理論的には、レガシー コードは時間の経過とともにリファクタリングされ、新しい場所に移動されますが、実際にはめったに起こりません。

レガシー コードをどのように扱いますか? 古い罪を「レガシー」フォルダーにしまい込み、二度と見たくないという誘惑に駆られるのと同じくらい、あるレベルでは、リポジトリ内のより「健康な」住人、おそらくレガシーコードはいつかうまくいく可能性が高くなりますか?

（ええ、私たちは皆、何かを書き直すべきではないことを知っていますが、これは私の「楽しい」リポジトリであり、私のビジネスプロジェクトではありません...）

アップデート

さまざまなバージョンを追跡する技術的な側面については心配していません。そのためにタグとブランチを使用する方法を知っています。これはより心理的な側面です。なぜなら、私はレポジトリに「きちんとした」構造を持たせたいと思っているからです。

サービスとして実装する必要がある既存の GUI アプリケーションがあります。基本的に、Windows 2003 サーバーにリモートでログオンおよびログオフし、このプログラムを引き続き実行できる必要があります。

これは可能ですか？

編集:ここでさらに改良します...ソースがありません。それは私のアプリケーションではありません。

Visual Studio 6を使用してまだ開発中の社内プロジェクトの数と、それらをVisualStudio2008に移行するための最善の方法について考えてきました。プロジェクトの範囲はC/C++とVBです。

VS2008にワークスペースをソリューションに変換させ、コンパイルエラーを修正して、順調に進んでもらう方がよいでしょうか。または、クリーンなソリューションから始めて、プロジェクトが途中でデッドコードを破棄することにより、プロジェクト全体でコードを移行する方がよいでしょうか。

#include ディレクティブを使用して、物理的な依存関係が大きいレガシー コード モジュールの単体テストを書き始めたところです。私は非常に退屈だと感じたいくつかの方法 (空のヘッダーを提供して長い #include 依存関係リストを分割し、#define を使用してクラスがコンパイルされないようにする) を処理してきましたが、これらの問題を処理するためのより良い戦略を探していました。

私は頻繁に、ほとんどすべてのヘッダー ファイルを空のバージョンで複製して、テストしているクラス全体を分離し、必要なオブジェクトの実質的なスタブ/モック/偽のコードを記述するという問題に遭遇しています。それらは現在未定義であるため、置き換えられました。

より良いプラクティスを知っている人はいますか？

膨大な数の従来のストアド プロシージャが機能していて、問題が発生しています。これらの手順をよりよく理解するのに役立つツールをお勧めしますか? プロシージャ間の依存関係および/またはプロシージャとテーブルの依存関係を特定するある種のリバース エンジニアリング。無料または商用のツールを使用できます。

ありがとう！