ほとんどの場合、文字列がコードに書き込まれるプロジェクトを開始しています。多くの文字列はいくつかの場所でのみ使用される可能性がありますが、一部の文字列は多くのページで共通です。
リテラルを定数にリファクタリングするのは、アプリが十分に確立されており、適切に実行されているということで、私の時間を有効に使っていますか? そうすることの長期的な利点は何ですか?
ほとんどの場合、文字列がコードに書き込まれるプロジェクトを開始しています。多くの文字列はいくつかの場所でのみ使用される可能性がありますが、一部の文字列は多くのページで共通です。
リテラルを定数にリファクタリングするのは、アプリが十分に確立されており、適切に実行されているということで、私の時間を有効に使っていますか? そうすることの長期的な利点は何ですか?
考慮すべき一般的なことの 1 つは、i18nです。あなた (またはあなたの意地悪な人) がメキシコやフランス (など) で製品を販売したい場合は、これらの文字列リテラルがコード ベース全体に散らばっていないことに感謝するでしょう。
編集:これはあなたの質問に直接答えないことを認識しているので、他の回答のいくつかに投票しています:3のルールなど。既存のコード ベースについて話していることは理解しています。そのため、最初から i18n を組み込むことについて話すのは少し遅れています。最初から習慣にしていると、とても簡単にできます。
私はリファクタリング時に 3 つのルールを適用するのが好きです。3 回以上発生する場合は、コードを更新する必要があります。
すべての共通文字列をリファクタリングすると、国際化/翻訳が容易になります。それらがすべてプロパティファイルにある場合、または対応する言語が何であれ、さらに簡単です。
このプロジェクトを将来にわたってサポートする必要がある場合にのみ、これは時間の有効な使い方です。このシステムを定期的に維持/拡張する場合。しかし、これは素晴らしいアイデアです。
1) 通常、単一のスペルミスは実行時にしか検出できないため、文字列リテラルには大きなリスクが伴います。実行時エラーのリスクが軽減されることは、恥ずかしい/イライラする可能性があるため、重大な利点です。
2) また、それらを変更する必要がある場合、たとえば、別のシステム (テーブル名、サーバー名など) を参照するために使用される場合、それらの他のシステム名が変更されたときに更新するのが非常に困難になる可能性があります。それらを一元化すれば、それは些細な問題です。
文字列が複数の場所で使用されている場合は、リファクタリングします。一か所だけ使用する場合はそのままにしておいてください。
リテラルを定数にリファクタリングするのは、アプリが十分に確立されており、適切に実行されているということで、私の時間を有効に使っていますか?
いいえ、そのままにしておくほうがいいです。
そうすることの長期的な利点は何ですか?
誰もそのコードに触れなければ、何のメリットもありません。
ただし、できることは、新しいリテラルを追加しないことです。しかし、私は彼らが存在する方法をほとんど残しておきます。
おそらく、自由にリファクタリングして、よりよく眠ることができます。
おそらく、注意が必要なバグが他にもいくつかあるはずです。代わりにそれらを修正してください。
最後に、「リファクタリング」をタスクリストに追加できたら、どうぞ!!!
私は JMD に同意します。i18n には文字列の変更以上のものがあることを覚えておいてください (通貨、UI は右から左への言語などに適応させる必要があります)。
アプリケーションを 18n したくない場合でも、文字列をリファクタリングすると便利です。なぜなら、その文字列は今日は 1 回だけ使用され、明日は数回再利用される可能性があり、ハードコーディングされている場合はそれに気付かない可能性があり、あらゆる場所で文字列を複製するスター。
眠っている犬を寝かせるのが一番です。18 回も使用された文字列を変更する必要がある場合は、どこかで定数に変更してください。定数化できる文字列を含むモジュールで作業していることに気付いた場合は、必要に応じて実行してください。しかし、アプリ全体を調べて、すべての文字列を定数に変更します...これは、to-do リストの一番下にあるはずです。