3

プライマリ言語としてVBScriptを使用して、ClassicASP上に構築されたWebアプリケーションを保守しています。私たちは、バックエンド（必要に応じてフレームワーク）が古く、迅速に前進するための適切なツールを提供していないことに同意します。私たちはいたるところにある現在のwebMVCパターンをほぼ受け入れており、現在のテクノロジーでは合理的な方法でそれを行うことはできません。欠けている大きな機能は、とりわけ、適切なディスパッチと継承によるテンプレートです。

現在、2つのパスが議論されています。

  1. JScriptを使用して既存のアプリケーションをClassicASPに移植します。これにより、問題なく.NET MSJscriptに移行し、最終的に.NETプラットフォームに移行できます（MVCの処理はASPで行われることが望ましいです。私たちの意見では、NETは現在よりもはるかに優れているわけではありません）。これは、少し時間がかかるかもしれませんが、次のオプションよりもリスクが少なく、より安全な方法であると主張されています。
  2. 他のテクノロジーを使用してアプリケーションを完全に書き直します。現在、パックのリーダーは、カスタムフレームワーク、ORM、および優れたテンプレートソリューションを備えたPythonWSGIです。ここには、djangoやその他の構築済みソリューションのための小刻みに動く余地があります。この方法は、実際の製品の横でベータ版を実行する可能性があるため、最も迅速な解決策になると思いますが、正しく実行できない/実行できない場合は、時間の無駄が大きくなる可能性があります。

これは、私たちが長年にわたって構築してきたものがかなり安定しているため、私たちの論理がなくなったことを意味するものではありません。これは、ストアドプロシージャを多用するSQL Server 2005上に構築されており、もう少し背景を説明するためにIIS6で公開されています。

さて、質問です。上記の2つのパスのいずれかをとった人はいますか？もしそうなら、それは成功したのか、どうすればもっと良かったのかなど。私たちはこれら2つのことのいずれかを行うことから大きく逸脱することは考えていませんが、いくつかの提案や他の解決策が役立つ可能性があります。

4

9 に答える 9

7

コードを捨てないでください！

これは、（大規模なコードベースで）犯す可能性のある最悪の間違いの 1 つです。してはいけないこと、パート 1を参照してください。

あなたはその古いコードに多大な労力を注ぎ、多くのバグを解決してきました。それを捨てるのは、典型的な開発者の間違いです (そして、私は何度もやったことがあります)。春の大掃除のように、気分が「良く」なります。しかし、家を整えるために新しいアパートやすべての新しい家具を購入する必要はありません。一度に作業できるのは 1 つの部屋だけです...新しい塗装作業が必要な場合もあります。したがって、ここでリファクタリングの出番です。

アプリの新しい機能については、C# で記述し、従来の ASP から呼び出します。この新しいコードを書き直すと、モジュール化を余儀なくされます。時間があるときに、古いコードの一部を C# にリファクタリングし、バグを修正していきます。最終的に、アプリをすべて新しいコードに置き換えます。

独自のコンパイラを作成することもできます。PHP を出力できるように、従来の ASP アプリ用にかなり前に作成しました。それはワサビと呼ばれていて、ジェフ・アトウッドがジョエル・スポルスキーがロッカーから離れたと思った理由だと思います。実際には、それを出荷するだけで、それを使用できるかもしれません。

ソースのごく一部を書き直すだけで、次のリリースに向けてコードベース全体を .NET に切り替えることができました。また、多くの人が私たちを狂ったと呼ぶ原因にもなりましたが、コンパイラを書くことはそれほど複雑ではなく、多くの柔軟性を与えてくれました。

また、これが内部のみのアプリである場合は、そのままにしておいてください。書き直さないでください。あなたは唯一の顧客であり、要件がクラシック ASP として実行する必要がある場合は、その要件を満たすことができます。

于 2008-09-18T02:19:51.713 に答える
3

それはあなたが信じているよりもうまくいきます。

最近、私は恐ろしい古い C コードのコレクションに対して大規模なリバース エンジニアリングの仕事をしました。機能ごとに、まだ関連性のある機能をクラスに再割り当てし、クラスの単体テストを作成し、代替アプリケーションのように見えるものを構築しました。クラスを通る元の「ロジックフロー」の一部があり、一部のクラスは設計が不十分でした [主に、これは、分解するのが難しすぎるグローバル変数のサブセットが原因でした]。

クラス レベルおよび全体的なアプリケーション レベルでの単体テストに合格しました。従来のソースは、ほとんどの場合、本当にあいまいなビジネス ルールを見つけ出すための一種の「C の仕様」として使用されていました。

昨年、30 年前の COBOL を置き換えるためのプロジェクト計画を書きました。顧客は Java に傾倒していました。計画作業の一環として、Django を使用して Python で改訂されたデータ モデルのプロトタイプを作成しました。計画を立てる前に、コア トランザクションのデモを行うことができました。

注: プロジェクト全体を計画するよりも、Django でモデルと管理インターフェイスを構築する方が迅速でした。

「Java を使用する必要がある」という考え方のため、結果として得られるプロジェクトは、Django デモを完成させるよりも大きくなり、費用もかかります。そのコストと釣り合う真の価値はありません。

また、Web アプリケーションにする必要がある VB デスクトップ アプリケーションに対しても、同じ基本的な「Django のプロトタイプ」を作成しました。Django でモデルを構築し、レガシー データをロードして、数週間で稼働しました。その作業用プロトタイプを使用して、残りの変換作業を指定しました。

注：残りの作業を計画するために使用した、機能する Django 実装 (モデルと管理ページのみ) がありました。

Django でこの種のプロトタイピングを行うことの最も優れた点は、モデル、単体テスト、および管理ページを、うまくいくまでいじることができることです。モデルが正しくなったら、残りの時間を、全員が満足するまでユーザー インターフェイスをいじることに費やすことができます。

于 2008-09-17T21:44:51.437 に答える
3

未使用の機能を削除する機会としてこれを使用してください。間違いなく新しい言語を使用してください。2.0 と呼んでください。本当に必要な 80% を再構築する作業は、はるかに少なくなります。

アプリケーション全体から脳を一掃することから始めます。全体的な目標のリストを用意してから、使用する機能に基づいて必要な機能を決定します。次に、それらの機能を念頭に置いて再設計し、構築します。

(コードを削除するのが大好きです。)

于 2008-09-17T20:53:43.213 に答える
2

何をするにしても、アプリケーションを一度にすべて移植する必要がない計画に従うことができるかどうかを確認してください。すべてを捨ててゼロから始めたいと思うかもしれませんが、徐々にそれを行うことができれば、間違いを犯してもそれほど費用がかからず、パニックを引き起こすこともありません。

于 2008-09-17T21:08:42.273 に答える
1

半年前、私はいくつかの主要なアーキテクチャ上の欠陥（テンプレートとコードの混合、コードの重複、あなたが名前を付けます...）を持っていた大きなWebアプリケーション（幸いにもすでにPythonで）を引き継ぎました。

私の計画は、最終的にシステムがWSGIに応答するようにすることですが、まだそこにはいません。私はそれを行うための最良の方法を見つけました、それは小さなステップです。過去6か月で、コードの再利用が増加し、進歩が加速しました。

私のために働いた一般原則：

  1. 使用またはコメントアウトされていないコードを破棄する
  2. 役に立たないコメントはすべて破棄してください
  3. アプリケーションのレイヤー階層（モデル、ビジネスロジック、ビュー/コントローラーロジック、表示ロジックなど）を定義します。これは、非常に明確なアーキテクチャである必要はありませんが、アプリケーションのさまざまな部分について考えるのに役立ち、コードをより適切に分類するのに役立ちます。
  4. 何かがこの階層に著しく違反している場合は、問題のあるコードを変更してください。コードを移動したり、別の場所で再コード化したりします。同時に、アプリケーションの残りの部分を調整して、古いコードの代わりにこのコードを使用します。もう使用しない場合は、古いものを捨ててください。
  5. APIをシンプルに保ちましょう！

進行は骨の折れるほど遅くなる可能性がありますが、それだけの価値があるはずです。

于 2008-09-19T10:56:06.033 に答える
0

2.0 (現在存在する、または予定されているより多くの機能) に移行しようとしないでください。代わりに、コード ベース (保守性/速度/wtf) に関する現在の問題を解決する目的で新しいプラットフォームを構築し、そこから移行してください。

于 2008-09-18T02:23:49.673 に答える
0

私は Michael Pryor と Joel に同意します。ほとんどの場合、既存のコード ベースをゼロから書き直すよりも進化させ続ける方が良い考えです。通常、パフォーマンスや柔軟性のために特定のコンポーネントを書き直したり、リファクタリングしたりする機会があります。

于 2009-06-15T02:33:35.893 に答える
0

Python への移行を検討している場合は、Django で管理者インターフェイスを書き直すことから始めることをお勧めします。これは、IIS で Python を起動して実行する (または Apache に移行する) という点で、いくつかの問題を解決するのに役立ちます。そういえばisapi-wsgi がオススメです。これは、IIS を起動して実行する最も簡単な方法です。

于 2009-02-27T00:10:31.847 に答える
0

私は JScript をお勧めしません。ASP.NET MVC は急速に成熟しており、最終化が進むにつれて ASP.NET MVC フレームワークを強化しながら、移行を開始できると思います。別のオプションは、ASP.NET w/Subsonic または NHibernate のようなものを使用することです。

于 2008-09-17T20:55:23.100 に答える