技術メモ

◆定数の配置場所
　　プロジェクト内で利用されるリソースは以下の1.～6.の配置場所が考えられる
　　①～③を考えて配置場所/扱い方を考える事
　　①更新頻度
　　②集中度
　　③アクセス度

　　1.ソース内にハードコーディング　　　↑集中[最低] 頻度[低] ｱｸｾｽ度[高]
　　2.ソース内に定数として配置[Local]　 ｜集中[低]　 頻度[低] ｱｸｾｽ度[高]
　　3.ソース内に定数として配置[Grobal]　｜集中[中]　 頻度[低] ｱｸｾｽ度[高]
　　4.リソースとして配置　　　　　　　　｜集中[高]　 頻度[中] ｱｸｾｽ度[高]
　　5.外部ストレージに配置[File]　　　　｜集中[高]　 頻度[高] ｱｸｾｽ度[中]
　　6.外部ストレージに配置[DB]　　　　　↓集中[高]　 頻度[高] ｱｸｾｽ度[低]

　　例）
　　　　内部コード系
　　　　　　更新頻度：低
　　　　　　集中度　：高以外でスコープに合わせた場所とする
　　　　　　ｱｸｾｽ度　：高

　　　　機能ID、メッセージIDの扱い
　　　　　　ある特定のルールで記述され且つ、それ以外の利用で記述される可能性が低いものはシンボル性が高い為、同一名の定数として扱うならば
　　　　　　定数にする必要性はない。なぜなら、同一名にしてしまうと仮にメッセージIDが変わった時に、変数名も変えなければならなくなる
　　　　　　　　例)メッセージID："EX121200"のものを
　　　　　　　　　 public const string MSG_EX121200 = "EX121200";として定数宣言する
　　　　　　一覧性、修正の容易さ、可読性の観点から集中管理がしたいのならば
　　　　　　シンボル性を低くして意味的な定数名を付ける事もありではある
　　　　　　　　例)public const string MSG_INVALID_ERR = "EX121200";
　　　　　　しかし、メッセージIDが膨大に膨れ上がった場合、一つ一つに意味のある定数名を付けていくことができるのかという問題と
　　　　　　そもそも分かりやすい定数名なんてものが意味があるのか？という問題がある
　　　　　　(日本語の定数名で記述できるのならばまだしも、大抵は短文省略英語で記述される。これは可読性に対して英数記号と大して変わらない
　　　　　　 のではないのか？)

　　　　　　メッセージIDの定数化に対する反論
　　　　　　①一覧性
　　　　　　　メッセージIDに正規表現で抜き出せる屹然としたルールが存在するならば、ツールを利用すれば抜き出せるので不要
　　　　　　②修正性
　　　　　　　①と同様に、正規表現で抜き出せさえすれば、置換も一括で行える
　　　　　　　※置換は行えるかもしれないが、本当に正しく置換されたかどうかを検証する必要があるか？