ここにいるプログラマーの中には、VB6でプロジェクトを開発している人もいます。彼らは、vb6が間もなく歴史になるので、アプリを新しい/将来のシステムで実行したい場合は、vb.netにアップグレードする必要があると言います。
したがって、彼らが取り組んでいるこの巨大なアプリケーションがあり、最初から再構築する必要があります（彼らはアップグレードウィザードを使用しようとしましたが、エラーが多すぎました）
会社の所有者は、プロジェクトに多くの時間を費やして、プロジェクトを一からやり直さなければならないことにそれほど興奮していません。
これは私のプロジェクトではなく、vbについては何も知りません。私はWebプログラマーです。
しかし、これが二度と起こらないように、これらの人は何ができるでしょうか、またはこれが今問題にならないように彼らは何をすべきでしたか？
アプリケーションが常にスケーラブルであり、時代遅れにならず、書き直す必要がないことを確認する方法はありますか？
ありがとう！
いいえ、実際には何もありませんが、Windows 7はまだDOSプログラムを実行できるため、プログラムが実行できなくなるわけではありません。彼らが遭遇する最大の問題は、新しいサポートや新機能がないことと、このテーマに関する知識のコミュニティが縮小していることです。
私の会社は現在、Fortran、Clipper、VB6、FoxProでプログラムを実行しています。そのうちのいくつかは、20年以上前から存在しており、すべてのWindowsアップグレードを無傷で生き延びてきました。通常、古いプログラムを使用できなくするのは、バグを修正するためにプログラムを再コンパイルできないことです。
プログラムの機能を分割することは確かに役立ちます。そのため、VB6からVB .Netに移行する場合は、再利用可能なコードを簡単に選択できます。
すばらしい質問です。
簡単な答えは「いいえ」です。すべてのコードが最終的に廃止されるためです。
x86アセンブラーでコードを記述した場合、それはしばらく続きます。Cコードの保存寿命も長くなります。しかし、問題は、テクノロジーがアセンブラーから抽象化されるほど、多くの要因によりその保管寿命が短くなることに伴います。
独自の言語を使用しないでください。確かにライブラリとプラットフォームは変わるかもしれませんが、言語自体が時代遅れになっているのは興味深いことです。C、C ++、またはオープンソースである大規模なユーザーベースを持つものに固執します。メンテナがサポートをやめたとしても、これらはしばらくの間存在する可能性があります。これは、Python、Ruby、Java、そしておそらくC＃を意味します。私の水晶玉はCとC++以外ではあまり良くありませんが、他の1つが20〜50年続くという説得力のある理由があります。
Visual Basicは楽しかったですが、それが促進するコードとUIの混合は、アーキテクチャの観点からはひどいものです。優れた設計により、バックエンド、GUIツールキット、およびOSの変更が可能になるはずです（必ずしも非常に簡単ではありません）。
あなたはちょっと言語にこだわっているので、絶えずそれを変えている1つのベンダーに制限されていないものを選んでください。
JoelによるFireandMotionを読んでみてください。
他の人が言っているように、それは「どうして私のアプリケーションを時代遅れにしないことができるか」ではありません。それは、「アプリケーションが陳腐化したときに、どうすれば迅速に回復できるか」ということです。そして実際、それは他の質問の単なる異なるバージョンです：
これは、OOとSOAが答えようとしていたことです。小さな独立したアプリケーションをたくさん構築し、標準のメカニズムを使用してそれらを緩く結合します。何らかの理由でアップグレードする必要がある場合は、引き出してアップグレードし、再び接続します。
メンテナンスされていないアプリケーションの陳腐化を防ぐための認識された方法を私は知りません。
製品が陳腐化するのを防ぎたい場合は、アップグレード可能になるように設計してください。
.NETでは、少なくとも、再利用可能なコンポーネントを作成するための多くのオプションがあります。
個別のアセンブリ。任意の.NETプロジェクトで使用でき、後で別のテクノロジを使用する必要が生じた場合にCOM相互運用機能をサポートするように拡張できます。
ウェブサービス; これらは公開され、ほとんどすべての環境から使用できます。
インターフェイスと制御の反転を使用して、自由に交換可能なコンポーネントをサポートできます。これは、理論的には.NETでもないもの（COMラッパーを作成するだけ）からのものである可能性があります。
プロセス間通信-他のすべてが失敗した場合は、文字通り、メモリマップトファイルまたは名前付きパイプを作成し、新しいアプリケーションから（または宛先に）データを送り始めることができます。
実際、これらの多くはおそらく現在のVBプロジェクトに当てはまります。通常、コア機能を新しいテクノロジーに徐々に移行しながら、既存の製品の耐用年数を延ばす方法は無数にあります。
私は筋金入りのSOAではありませんが、これはまさにSOAが解決しようとしている種類の問題です。私は多くのサービスを行っています-実際、ここで重要なほとんどすべては、ある時点で何らかのWebサービスを経由します-いつでもサービスを完全に取り除いて、上のサービスに置き換えることができることを知っているので、非常に快適です。別のプラットフォーム。それがしなければならないのはSOAPまたはJSONを吐き出すことだけであり、私の.NETクライアントはそれをまだ消費することができます。または、クライアントを置き換える必要がある場合は、サービスにすでに存在するリッチドメインモデルに接続することもできます。
実際、私はすでにこれを行っています。アーキテクチャは、Delphi7プラットフォーム上に完全に構築されていました。現在はすべて.NET3.5上にあり、あるシステムから次のシステムへのハードカットオーバーは実際にはありませんでした。プレーンなSOAPサービスの構築を開始し、アプリケーション内のビジネスロジックの多くをサービスに移動しました。最終的に、アプリケーションがシェルにすぎなかったときに、いくつかの.NETクライアントに置き換えました（いくつかあります）。その後、新しいプラットフォームでのみサポートできるさまざまなセキュリティ機能と最適化の追加を開始しました。などなど。
したがって、事前に計画を立てれば、間違いなく実行できます。もちろん、ここにはYAGNIを引用して、事前の計画に反対するアドバイスをする人がたくさんいます...そして、特定のプロジェクトについてはそうかもしれません。それはすべて、プロジェクトがどれだけ高価でミッションクリティカルであるかに依存します。製品を50年間使用する必要がある場合は、サブコンポーネントの追加と削除を簡単にする堅固なアーキテクチャと設計への投資を検討することをお勧めします。
プログラミングを取り巻くテクノロジーの急速な進化を考えると、時代遅れになることは、私たちのアプリケーションの通常のライブサイクルの一部です。
デスクトップ/サーバーアプリケーションについてはよくわかりませんが、Web開発では、たとえば5年は長いと言います^^
もちろん、更新、パッチ適用、修正、修正などは可能ですが、そうすると、一般的にコードの品質とアプリケーション自体の品質が低下する傾向があります。つまり、時間の経過とともにメンテナンスのコストが高くなります。 ; 結局、すべてを書き直すことは、おそらくメンテナンスに費やすお金を減らすことを意味します。
そもそもVB6でこのプロジェクトを書くのが良い考えだと思った理由を自問する必要があります。彼らはそれがすでにサポートされておらず、時代遅れであることを知りませんでしたか？時代遅れのテクノロジーを使い始めた場合、何を期待できるでしょうか。
また、VB6コードの構造を改善し、オブジェクト指向にすることも検討する必要があります。これにより、.NETへの移行が容易になります。特に、COMを介してアクセスされる外部クラスに機能を分離してみることができます。これらの同じクラスには、VB.NETからアクセスできます。さらに、これらの小さな部分は移行が簡単な場合があります。
最良の方法は、クロスプラットフォームの開発ツールとライブラリを使用することです。そうすれば、Microsoftはあなたが依存しているものを非難することはできません（彼らはそれらを制御していないので）。単一のベンダーからの特定のものに依存している場合、それらはある時点であなたを台無しにする可能性があります。
現在本格的に使用されている標準（ANSIまたはISO、ECMAは避けます）の定義に書き込みます。1つの会社に依存しているものや、完全な実装が1つの会社からのものだけである場合は避けてください。ベンダーの言語拡張機能は使用しないでください。データ型のサイズなど、言語に関する仮定を避けるように注意してください。intではなくメモリサイズを保持するために使用size_tすると、64ビットシステムでの実行がより困難になる可能性があります。
Microsoftは、下位互換性を維持している企業の中でも注目に値するものであり、VB6を破ったことを忘れないでください。他の会社はおそらくもっと悪いでしょう。
重要なアプリケーションでは、プラットフォームに依存する部分があります。プラットフォームが変更された場合に何を書き直す必要があるかを制限するために、それらを分離します。
明らかに、これにはコストがかかります。たとえば、WindowsアプリケーションはVisual C ++で実行し、抽象化レイヤーを介してMFCを使用することをお勧めします。これは、C＃、. NET、VB.NET、およびF＃が私の基準に該当しないためです。しかし、それがあなたの目標であるならば、これは長続きするプログラムを作成する方法です。
廃止できないコードに焦点を当てないでください。該当するスタックで作業することはめったにありません。代わりに、コードを明確かつ簡潔にして、必要なときに移行できるようにします。代わりに、自分が時代遅れにならないようにすることに焦点を合わせてください。最新の状態を維持し、スタックで何が起こっているかを把握し、スタックに完全に適用するための時間を割くことができない場合でも、何が起こっているかを認識してください。
エミュレーションと仮想マシンを考えると、「レガシー」コードは実際には以前に想像されていたよりもさらに長寿命になると思います。心配する必要があるのは、OSではなく、ツールです。
これは（おそらく）コードをデザインから分離することに依存します。特に、ファッションの変動に非常にさらされることが多いWebアプリケーションではそうです。ただし、コードベースは現在のテクノロジで実行可能です。つまり、OSは引き続き実行できるため、「アップグレード」する理由はありません。
コードを永久に存続させるための本当の方法は、使用に不可欠になるが書き直しに費用がかかるため、OSやハードウェアを廃止しないことを含め、すべてが実行を継続するために行われるアプリケーションを作成することです。この一例は、米国の社会保障/政府の分野のいくつかのコアシステムが、1960年代初頭のCOBOLで作成され、古いIBMメインフレームで実行されていることだと思います。
それをオープンソース化するか、少なくともオープンソースプラットフォーム上に構築します。
1970年代のプロプライエタリシステムで、以前の使用法と互換性のある方法で使用しているものはありませんが、多くのオープンソースシステムを知っています。
これは完全なメカニズムではありません。すべての言語はこれらのタイムスケールでわずかに変化します。その後、最新のものを入手するには、コードをアップグレードする必要があります。しかし、私は何十年も変更なしで存在しているコードを実行しているサーバーをたくさん知っています。
さらに良いことに、それをオープンソース化するか、可能な限りオープンソース化します。他の人があなたのためにそれを更新している間、何もできないことよりもさらに良いことは何もできないことです。コミュニティを始めるには手間がかかりますが、一度始めたら止めるのは難しいかもしれません！
非オープンソースプログラムの効用は、有限時間後にゼロに低下します。オープンソースがゼロ以外のままになるという保証はありませんが、少なくともチャンスはあります。
申し訳ありませんが、2月にこの質問を見逃したに違いありません。私が見る限り、.Netに移行するには、[VB6アプリ]を最初から再構築する必要があるという同僚の結論に誰も対処していません。
これは間違っています。書き直す必要はありません。別の方法があり、通常、完全な書き直しよりもはるかに簡単で安価です。
MicrosoftUKからの公式アドバイスは次のとおりです。
.NETへの完全な書き換えを実行することは、[変換するよりも]はるかにコストがかかり、うまく実行するのが困難です...少数の状況でのみこのアプローチをお勧めします。
書き直しについて相談したMicrosoftの人によるブログ投稿から：
.NETの初期に私が協力していた多くの企業は、.NETに移行すると同時に、基盤となるアーキテクチャとコード構造を改善したいという強い願望に一部駆り立てられて、最初に書き換えを検討しました。残念ながら、これらのプロジェクトの多くは困難に直面し、いくつかは完了しませんでした。彼らが解決しようとしていた問題は大きすぎました。[これは、同僚が上司と深刻な問題を抱えるポイントです。この時点で人々は解雇されます]
VB6-> VB.Net移行の5つの基本オプションを説明するスクリーンキャストを使用して、MicrosoftUKのアドバイスを確認するように同僚に伝えます。彼らは上司と協力して前進する方法を選択する必要があります。書き直しかもしれませんが、目を開けて入る必要があります。
そして、彼らはおそらくVB6で他に何か新しいことを書くべきではありません...