問題タブ [legacy]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
83 参照

scheduling - Manugistics/Avyx Forest および Trees スケジューリング ユーティリティ

1994 年に、誰かが、森林と樹木を定義するソフトウェアのスケジューリング パッケージを利用して、NASA のスケジューリング パッケージを書きました。1 つのライブラリを除いて、パッケージの完全なソースがあります。インクルード ファイルのどこにもそれを書いた人を示すものはありませんが、それが Manugistics であると信じる理由があります。誰でも洞察を提供できますか?

0 投票する
3 に答える
547 参照

.net - レガシー コード、レガシー ツール - 何をすべきか?

レガシーと呼ぶ少し古いプロジェクトがあります。

それのいくつかの特徴は次のとおりです。

  1. これは (約 3 年間) 動作する製品であり、継続的に開発されています。
  2. コードベースはかなり大きく、含まれています (CS、SQL、ASPX、Jayrock、JS/HTML/CSS など)
  3. プラットフォームは .NET 1.1 です。
  4. IDE は Borland C# Builder 2006 です (なんと...)。
  5. その他のツールは、Enterprise Core Objects 3 (.NET 1.1 用) (モデル駆動型アーキテクチャ - UML からの O/RM) です。
  6. さらに、Telerik RadControls が使用されます。
  7. ほとんどが 1 人のアクティブな開発者です。
  8. ビジネス オブジェクトのテストは多数ありますが、UI (Web フォーム) はテスト可能な ATM ではありません (MVP/MVC が適用されていないなど)。
  9. コードの品質が「最高」ではなく、「十分」というマークのままであることを認めなければなりません (したがって、これはすべてを最初から書き直す主な理由ではありません) 。

このプロジェクトの問題点は次のとおりです。

  1. .NET 1.1 - プラットフォームはもはや「アクティブ」ではありません。
  2. IDE - 常に苦労しています。働くのはただの苦痛です。ツールのサポートが悪く、リファクタリングは基本的に手作業で行われます。
  3. ECO3 フレームワーク - ECO5 (および .NET 3.5) に移行するには多大な労力が必要です。
  4. ECO3 から NHibernate への移行 (推奨) にはさらに時間がかかります (すべてのロジック/テストを書き直す必要があるため)。
  5. ECO3 は IDE に大きく依存しているため、IDE のみを変更することはほとんど不可能です。
  6. 一般に、.NET 3.5 への移行には多くの時間がかかります (特に 1 つの開発者のみ)。

このプロジェクトに対処する方法についての推奨事項/ヒントを聞きたいです。
その環境で仕事を続けるべきですか?
そうでない場合、プロジェクト全体を数日以内に移行する最善の方法は何ですか (数週間の遅延は長すぎる ATM)。はい、後で報われることは理解していますが、今はできません。

通常、提案は大歓迎です。

乾杯、
ドミトリー。

0 投票する
6 に答える
535 参照

architecture - レガシー アプリケーションを再構築するための戦略

.Net WPF でいくつかのレガシー COM アプリケーションを再構築するという新しい課題がまもなくやってくる予定です。可能であれば、機能や既存のコードを再利用する必要がありますが、その範囲は限られていると思います。

既存の機能を複製する必要がありますが、最新の拡張可能なアーキテクチャを使用して実現する必要があります。

このタイプのプロジェクトにアプローチするための一般的なアドバイスはありますか? このテーマに関する適切なリソースはありますか?

試行錯誤された手法や一般的な落とし穴はありますか?

0 投票する
1 に答える
386 参照

python - Django と奇妙なレガシー データベース テーブル

Django にレガシー データベースを統合しようとしています。

ひどく悪いデータベース設計の結果、いくつかの奇妙なテーブルで問題が発生していますが、それを自由に変更することはできません。

問題は、主キーIDではなく製品IDを持つテーブルがあることです。ここで問題が発生します。たとえば、特定の列に複数の値が必要な場合、それらの多くは複数です。

通常の主キーの動作を回避し、複数の行を持つそのような ID のオブジェクトを返す関数を作成する可能性はありますか? その場合、列の名前文字列はリストになる可能性があります。

これは別のシステムからエクスポートされたデータであるため、手動で編集する必要はありません。アクセスするだけです..

0 投票する
5 に答える
1452 参照

xml - XML やその他のマークアップ言語の利点を説明してください

2 つのシステム間で構造化された形式でデータを送信することの利点を、会社の上級職員に納得させようとしています。

現在、一方のシステムはフラット テキスト ファイルを出力し、もう一方の側でデータを抽出するには複雑なパーサーを作成する必要があります。データが変更されるたびに、「位置」を調整する必要があり、保守とテストは頭痛の種です。

どちらの側にも XML を作成および操作するための機能が組み込まれているため、私が求めているのは説得力のある記事、ドキュメント、ブログ投稿などで、XML (または実際には他のマークアップ言語) をフラット テキストの代替として紹介することで、以前にそれを使用したことはありません。

どうもありがとう

0 投票する
1 に答える
127 参照

c - レガシーGTKアプリケーションから最新のGTKビルダーベースのアプリケーションにインターフェースを移行するためのツールはありますか

私は、時代を示し始めている多くのレガシーCベースのGTKアプリケーションを担当しています。私はそれらのいくつかをより現代的なフレームワークで再実装するという考えをいじっています。手作りのCベースのGTKインターフェースをGTKビルダーベースのXMLインターフェース記述に移行するのに役立つツールはありますか?私の目的は、インターフェース定義を実際のアプリの実装から分離することです。

アプリをltraceし、GTKライブラリ呼び出しからインターフェイスを再構築することは可能かもしれないと思いますが、誰かがすでに問題を解決している場合は、車輪の再発明をしなくてもかまいません。

0 投票する
3 に答える
1560 参照

c++ - 巨大なレガシーコードベースのMSTest

約10万行のネイティブ/アンマネージドレガシーc++コードを含む巨大なコードベースがあり、コードに単体テストを提供し、MSTestは現在の開発環境(TFS、VS 2010など)に完全に適合します。MSTestは元々マネージコードをテストすることを目的としていますが、アンマネージscの単体テストを作成することも可能です。

管理されていないコードに対するMSTestの使用に(後で)欠点はありますか?誰かがこれについて何か経験がありますか?

セカンドオピニオンはGoogle.Testを使用することですが、gtestフレームワークを環境に統合するためにVisualStudioアドインを作成する必要があります。

前もって感謝します!

0 投票する
1 に答える
141 参照

perl - Catalyst の一部を従来の Web アプリケーションに統合するにはどうすればよいですか?

私は古典的なレガシープロジェクトに苦労しています.手動のURL解析と構成、手動ルーティングなど.少しのCatalystを知っているので、少なくともいくつかの概念、たとえば適切な(透過的な)URLルーティングとパラメータ解析などを切望しています. 理想的には、Catalyst をそのまま使用して終了するのが理想ですが、これがレガシー プロジェクトであることを考えると、次の 2 つのオプションしかないと思います。

  1. どういうわけか、私のプロジェクトで Catalyst の一部を使用しますが、それが可能かどうかはわかりません。それは...ですか?
  2. Catalyst のフレームワークの一部を実装する単一のモジュールを使用します。どのような経験がありますか?どのモジュールを推奨できますか?
0 投票する
1 に答える
660 参照

architecture - AOP またはその他の自動化された手段を介して厄介なレガシー システムをリファクタリングしますか?

私は最近 PostSharp をいじっていて、数年前に直面した問題を思い出しました: クライアントの開発者が Web アプリケーションを作成しましたが、状態情報の管理方法についてあまり考えていませんでした。IIS のアプリケーション インスタンスで静的に(理由は聞かないでください) 。言うまでもなく、システムは拡張できず、深刻な欠陥があり、不安定でした。しかし、それは大規模で非常に複雑なシステムであったため、再開発のコストは法外なものでした。当時の私の要約は、コードベースをリファクタリングして、コンポーネント間の適切な分離を強制することでした。

当時、何らかの抽象化メカニズムを使用して、静的リソースへのすべての呼び出しをインターセプトし、状態データを適切に管理するコンポーネントにリダイレクトできるようにしようとしました。問題は、リダイレクトする複雑な参照が約 1000 あったことでした (そして、私にはそれを行う時間があまりありませんでした)。手動コーディング (R# を使用した場合でも) は時間がかかりすぎることが判明しました。コードベースを廃棄し、適当に書き直しました。書き直すのに1年以上かかりました。

私が今疑問に思っているのは、アセンブリ リライターやアスペクト指向プログラミング システム (PostSharp など) にアクセスできた場合、直接参照を見つけるリファクタリング プロセスを簡単に自動化し、それらをリダイレクト可能なインターフェイス参照に変換できたでしょうか。工場によって自動的に供給されます。

PostSharp または類似のシステムを使用して、病的なレガシー システムを修復した人はいますか? プロジェクトはどの程度成功しましたか? 後になって、その努力に見合うだけの価値があると思いましたか? もう一度やりますか?

更新: 詳細については、このブログ投稿を参照してください。