メッセージの管理

とあるシステムで。


(*)文化の違いなので、批判ではなく、私的に合点がいかなかった事項。

小規模システムならば、直接リテラルを記述するのもアリと思ってますが、そこそこ大きくなると、メッセージにIDを振って、ProgramからはメッセージIDで表示するのが定番です。



このメッセージIDの振り方にローカルルールがあるようです。

一般的には、 ID構成が 種類 + 応答+ 連番 + 表示文字列 になっているのが多いようです。

　　　種類 : 情報/警告/エラー

　　　応答 : OK/ OKCancel/ YesNo....

　　　連番 : 1～

　　　表示文字列: データ更新します。いいですか......



あるシステムのルールでは、表示文字列の読み仮名をベースに連番を振るようです。

あ: 01000番台 い: 02000番台 .....お: 05000番台

か: 11000番台　き: 12000番台 .....こ: 15000番台

: : :

わ: 9100番台



「データ登録します。」だと、"で"なので　ID=34001: となります。

「DBに接続できません」でと、"ディービーに接続"と読みる、　ID=34002か振られます。



最初の登録時に文言に依存してIDが決まる。

でも最初に設定した文言が不適切で、文言修正したい事は、よくある話です。

「更新しました」を「修正しました」に直すのもありそうです。このばあい、15000番台がら22000番台に変わることになり、

プログラムの引用箇所の修正も発生します。

ロジック以外の要因でソースに手を加えるのは、抵抗感があります。デグレの原因にもなります。

不具合誘発よりも、番号管理を優先にしているようで、本末転倒に映ります(私的にですが)

顧客IDの付け方も、同様の読み方ベースで付けているシステムがあります。結婚や合併で名称が変わったらどうするのでしょうね。

コボル全盛期には、変数名台帳、関数名台帳などを作って、それらを用いた管理が、進捗管理だと錯覚している管理部署がありました。

その文化で育った人には、リファクタリングは、悪魔の誘惑に見えるそうです。



関数名や変数名、顧客IDなんてアイウエオ順で単純管理できるものではないので、管理対象ではないと主張しているのですが、既存ルールを変えるとこまで行かないのは、力のなさかな。