システムのオーバーホールが必要であると判断された場合、どのような最善の方法をとればよいでしょうか?

https://stackoverflow.com/questions/87522

01-07-2019
|

質問

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

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

JScript を使用して既存のアプリケーションをクラシック ASP に移植します。これにより、そこから大きな問題なく .NET MSJscript に移行でき、最終的には .NET プラットフォームに到達できるようになります (ASP では、それまでに MVC の作業が完了していることが望ましいです)。私たちの意見では、NET は現在よりもそれほど優れているわけではありません)。これは、多少時間がかかるかもしれませんが、次のオプションよりもリスクが少なく、より安全な方法であると主張されています。
他のテクノロジーを使用してアプリケーションを完全に書き直します。現時点でそのパックのリーダーは、カスタムフレームワーク、ORM、優れたテンプレートソリューションを備えた Python WSGI です。ここには、django やその他の事前構築されたソリューションでも柔軟に対応できる余地があります。おそらく実際の製品の横でベータ版を実行することになるため、この方法が最も迅速な解決策であることを願っていますが、正しく実行できない場合、または正しく実行できない場合は、大きな時間の無駄になる可能性があります。

これは、私たちのロジックがなくなったという意味ではありません。対処が難しいとだけ述べたように、私たちが長年にわたって構築してきたものはかなり安定しています。これはストアドプロシージャを多用して SQL Server 2005 上に構築されており、背景情報をもう少し説明するために IIS 6 上で公開されています。

さて、質問です。上記の 2 つの道のいずれかを選択した人はいますか?もしそうなら、それはうまくいきましたか、どうしたらもっと良くなったでしょうか、など。これら 2 つのうちの 1 つを実行することから大きく逸脱するつもりはありませんが、いくつかの提案や他の解決策が役立つ可能性があります。

解決

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

これは、(大規模なコードベースで) 犯し得る最悪の間違いです。見る絶対にやってはいけないことその1.

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

アプリの新しい機能については、 C# で作成し、従来の ASP から呼び出します. 。この新しいコードを書き直すときは、モジュール化する必要があります。時間があるときに、古いコードの一部を C# にリファクタリングし、バグを解決しながら進めてください。最終的には、アプリをすべて新しいコードに置き換えることになります。

独自のコンパイラを作成することもできます。私たちはずっと前に、PHP を出力できるようにするために、古典的な ASP アプリ用に 1 つを作成しました。それは呼ばれていますわさびそれが、ジェフ・アトウッドがジョエル・スポルスキーがロッカーを離れたと思った理由だと思います。実際のところ、それを出荷して、それを使ってもらったほうがいいかもしれません。

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

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

他のヒント

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

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

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

信じられないほどうまくいきます。

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

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

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

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

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

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

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

Django でこの種のプロトタイピングを行う最も良い点は、モデル、単体テスト、管理ページを納得するまでいじることができることです。右. 。モデルが適切であれば、残りの時間を全員が満足するまでユーザーインターフェイスをいじることができます。

何をするにしても、アプリケーションを一度にすべて移植する必要がない計画に従うことができるかどうかを確認してください。すべてを捨てて、最初から始めたくなる誘惑にかられますが、徐々に実行できるようになれば、失敗してもそれほど大きな損害が発生したり、それほどパニックを引き起こすことはありません。

半年前、私は大きなアーキテクチャ上の欠陥 (テンプレートとコードの混在、コードの重複など) があった大規模な Web アプリケーション (幸いなことにすでに Python で作られていました) を引き継ぎました。

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

私にとってうまくいった一般原則:

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

進歩は骨の折れるほど遅いかもしれませんが、それだけの価値はあるはずです。

JScript は間違いなく人が少ない道なので、お勧めしません。ASP.NET MVC は急速に成熟しているため、ASP.NET MVC フレームワークの完成に合わせて移行を開始し、同時に ASP.NET MVC フレームワークを強化することもできると思います。もう 1 つのオプションは、Subsonic または NHibernate を備えた ASP.NET などを使用することです。

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

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

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow