1

次のメジャー リリースでは、ASP.Net アプリケーションのグローバル化を目指しており、この取り組みで既に作業を行ったコードを追跡する方法を考えるように依頼されました。

私の考えは、カスタム属性を使用して、「修正」されたすべてのクラスに配置することでした。

どう思いますか?

誰かがより良いアイデアを持っていますか?

4

3 に答える 3

1

属性を使用してどのクラスがグローバル化されているかを判断するには、コードを処理し、「処理」されているクラスとされていないクラスを判断するツールが必要になります。少し複雑になっているようです。

より伝統的なプロジェクト トラッキング プロセスの方がおそらく優れているでしょう。また、グローバリゼーション プロジェクトの終了後に機能的な意味を持たない属性やその他のマークアップでコードを「汚染」することもありません。作業が必要なクラスごとに欠陥を提起し、そのように追跡するのはどうですか?

于 2008-09-29T20:11:28.887 に答える
0

クラスを数えたりリストしたりしてから、クラスごとに作業するのはどうですか? 属性は興味深いアイデアかもしれませんが、過剰に設計されていると思います。グローバル化は、各クラスを調べてコードをグローバル化するだけです:)

いずれにせよ、次のリリースの前にそれを完了したいと考えています。それでは、1つずつ実行してください。そうすれば、進歩が見られます。クラスごとに発生する欠陥も多すぎると思います。

私の最後のプロジェクトでは、少し遅れて完全なグローバル化を開始しました。コード ファイルのリストを上から下に見ていきました。私の場合はアルファベット順、フォルダごとにフォルダ。そのため、最後に作業したファイルを常に覚えておくだけで済みました。それは私にとってはかなりうまくいきました。

編集: 別のこと: 私の最後のプロジェクトでは、グローバル化には主に、ハードコーディングされた文字列をリソース ファイルに移動し、実行時に言語が変更されたときにすべてのテキストを再生成することが含まれていました。ただし、数値形式などについても考慮する必要があります。Microsoft の FxCop は、カルチャを違反として指定せずにすべての数値変換などをマークするため、これに役立ちました。FxCop はこれを追跡するため、そのような違反を解決して FxCop を再実行すると、違反が見つからない (つまり解決された) と報告されます。これは、これらの見にくいものに特に役立ちます。

于 2008-09-29T20:21:55.337 に答える
0

アプリ内の各ページの単体テストを作成するのはどうですか? 単体テストはページをロードし、

foreach (System.Web.UI.Control c in Page.Controls)
{
    //Do work here
}

作業部分については、さまざまなグローバリゼーション設定を読み込み、.Text プロパティ (またはアプリの関連プロパティ) が異なるかどうかを確認します。

私の仮定は、最も単純なケースを除いて、どの言語も同じ結果になるべきではないということです。

正常に完了した単体テストのセットを使用して、進行状況を追跡します。

于 2008-10-09T19:18:46.380 に答える