グローバリゼーションの進捗状況の追跡

Question

次のメジャーリリースでは、ASP.Netアプリケーションのグローバル化を検討しており、この取り組みでどのコードが既に処理されているかを追跡する方法を考えるように頼まれました。

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

あなたはどう思いますか？

より良いアイデアはありますか？

Answer 1

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

より伝統的なプロジェクト追跡プロセスはおそらくより良いでしょう-そして、「汚染」しません;グローバリゼーションプロジェクトの終了後に機能的な意味を持たない属性/その他のマークアップを含むコード。作業が必要なクラスごとに欠陥を発生させ、そのように追跡してみてはどうですか？

Answer 2

クラスをカウントまたはリストし、クラスごとに作業するのはどうですか？属性は興味深いアイデアかもしれませんが、過剰に設計されていると考えています。グローバル化は、各クラスを通過してコードをグローバル化するだけです：）

次のリリースの前にとにかくそれを終了したい。それで、先に進んで、一つずつそれをしてください、そして、あなたはあなたの進歩を持っています。各クラスで発生した欠陥は多すぎると考えています。

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

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

Answer 3

アプリの各ページの単体テストを書くのはどうですか？単体テストはページをロードし、

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

作業部分では、異なるグローバリゼーション設定をロードし、.Textプロパティ（またはアプリの関連プロパティ）が異なるかどうかを確認します。

私の想定では、最も単純な場合を除いて、どの言語も同じように出力されるべきではありません。

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