4

Delphi 1以降に存在する大規模なSQL駆動型ソフトウェアシステムがあります。これは、さまざまなプロジェクトすべてで同じ元のプロジェクトファイルを使用します。最近、Delphi XE2へのアップグレードを開始しました。新しいプロジェクトファイルを作成し、すべてのソースを再度追加して、新しいDelphiXE2プロジェクトの推奨されるデフォルトを確実に取得することを検討しています。

誰かがこれをお勧めしますか？そして、リスクは何ですか？明らかに、バージョン番号、プロジェクト名/説明/会社情報などを再定義するのは難しい作業です。しかし、私を怖がらせるのは元のプロジェクトのサイズです。3つの主要な実行可能ファイルに加えて他の多くの実行可能ファイルを合計すると、おそらく合計で300万行近くのコードになります。

これを行うことを考えている主な理由は、新しいDelphi XE2プロジェクトがプラットフォームおよびリリース（Win32、Win64、デバッグ、リリースなど）ごとにサブディレクトリを自動的に作成する方法を確認したためです。私たちのプロジェクトは現在混乱していて、私はそれをクリーンアップしようとしています。

では、これにはリスクがあると思いますか？そして、なぜ、またはなぜこれは良い考えではないのですか？デフォルトを「リセット」する代わりの方法はありますか？

4

3 に答える 3

13

プロジェクトファイルを再作成しても問題はありませんが、有用なものを追加することもできません。私はあなたのモチベーションに真剣に疑問を投げかけ、変更する必要があるものだけを変更することを検討します。

私たちのプロジェクトは現在混乱していて、私はそれをクリーンアップしようとしています。

大きなプロジェクトに携わってきた人なら誰でも、おそらくある時点でそれを考えているでしょう。本当にどこかに「混乱」がある場合、それは実際のプロジェクトファイルではなくプロジェクトのソースファイル（PAS、DFM）にあります。リファクタリングはおそらく逆の方向に進むはずです。ソースファイルを再編成し（必要な場合）、冗長であることが証明されているファイルを削除すると、プロジェクトファイルに新しく見つかったクリーン度がすぐに反映されます。

明らかに、バージョン番号、プロジェクト名/説明/会社情報などを再定義することは難しい作業です。

プロジェクトのオプションの1ページにすべてあります。私は正直に言って、それがあなたがしなければならない最も難しいことになるだろうとは思っていません。サードパーティのコンポーネントやその他の社内プロジェクトへのハードコードされた依存関係を発見する可能性がはるかに高くなります。コンパイラが文句を言う1つのユニットを修正して、何度もReBuildを押すので、これらを追跡するのは面倒です。

プロジェクトファイルには、プロジェクトを構成するファイルがリストされ、コンパイラオプションと定義の最小限のセットが含まれているという考え方です。プロジェクトファイルを再作成すると、すべてのコンパイラオプションと定義が追加され、リストは実際にコード化されているため、ファイルを1つずつ追加し直します。usesプロジェクトを構成するファイルの句。戻らないファイルは、プロジェクトのフォルダー内の検索パスにあるファイルと、本当に冗長なファイルだけです。冗長なファイルを削除したい場合、これは行く方法ではありません。ある種の使用リストアナラ​​イザーをよく調べてください。

これを行うことを考えている主な理由は、新しいDelphi XE2プロジェクトがプラットフォームおよびリリース（Win32、Win64、デバッグ、リリースなど）ごとにサブディレクトリを自動的に作成する方法を確認したためです。

そのためにプロジェクトファイルを再作成する必要はありません。プロジェクトのコンパイラオプションのOutput Directoryとを次のように変更するだけです。Unit Output Directory

.\$(Platform)\$(Config)
于 2012-01-23T07:39:19.167 に答える
2

One thing you need to be wary of if you go about recreating the .dpr is making sure that your units don't have any hidden interdependencies that will spring up and make your app misbehave in strange ways.

In fact, we ran into exactly this recently. Avoiding the backstory of why it was done, one of my coworkers created a new project and re-added all of a current (legacy) project's units. After rebuilding, the new executable threw access violations and then put a dialog prompt up on screen where he couldn't find the reason for its access.

It turns out there are quite a few dependencies between items (e.g. A form's OnCreate calling methods in datamodules) that caused the AVs, and the wrong form was being created first, making it the app's main form. The original project source had all the items added in a particular order to ensure that. When he recreated the project, he added all the units from Explorer in their native order -- alphabetical.

Now, you could use this as an opportunity to refactor your application to ensure that these kinds of timing issues and dependencies aren't a problem and perhaps disable form-auto create so that the only forms that are active in your app are the ones you need at any given point in time. Or you could just carefully modify the options directly to match the new defaults, if they make more sense for your project than the old ones.

于 2012-01-23T16:08:15.087 に答える
0

害はないはずですが、あなたが多くの利益を得られるかどうかはわかりません.

このようなアイデアに費やされた労力と時間は、埋め合わせのプロジェクトのように思えます。

製品の測定可能な改善を実際に行うことに時間を費やす方がよいでしょう。プロジェクトを再作成しようとするのは時間の無駄です。

于 2012-01-24T03:22:54.323 に答える