ものすごい HttpSession の使い方してるコードに出会ってしまった。どんな使い方か端的に言えば、セッションに 5,6 個のフラグ乗っていてアクションはこのフラグを基に振る舞いが決まる。その振る舞い次第でフラグの値も随時更新される。
セッションにバインドされるオブジェクトはこんなかんじ。
public class HogeFlags {
private String flag1;
private String flag2;
private String flag3;
}フラグなのに String なのだが、ここには "0" とか "1" とかが入る。null や空文字で初期化されるので、取り得る値が 0 or 1 だとしても null と空文字も考慮に入れる必要があるので実質 3 〜 4 値フラグになってます。0 〜 4 ぐらいまで値域があるヤツもいます。んでまぁ、アクションはこのフラグを処理するために大量の if 分岐で構成されている。そんなアクションが 2 桁以上あり、その遷移中にフラグの値はどんどん切り替わる。
アクション A 呼んだ後じゃないとアクション B は動かない、みたいな暗黙の了解が大量にあるので動作の推測は難易度 S ランク。アクションの動作がセッション中のフラグ状態に依存しまくってるので URL 直叩きしようものなら何が起こるかサッパリです。
更に厳しいことに、フォームパラメータからもフラグが何個かわたってくるケース多々。付け加えて、DB のフラグも参照する。つまり･･･
- セッションに格納されてるフラグ値
- フォームパラメータで渡されるフラグ値
- DB のフラグ値
によって、あるアクションの動作が決定される。5 次元ぐらいの状態遷移表作れば整理できるかもしらん。まぁ作れたとしてもまともな人類に読めるかどうかはわからんけど。
DB もセッションもある意味グローバル変数みたいなもんなので、そこに大量のフラグ使われるとソースコードが迷路魔境と化すことが良くわかりました。
元々の仕様がかなり複雑なので悶絶フラグ機構になってるっぽいのだが、テーブル駆動のやり方取り入れれば多少はマシになるハズ･･･。
