現実社会においては、全体の仕様から外れるような例外的な要件というのが割に高頻度で発生する。この○○だけは××になるようにしたい。「このクライアントだけは」「このユーザーだけは」「この画像だけは」、理由は広告だったり会社の力関係だったり、なにかのもめ事だったりと様々だが、まあしょっちゅう発生する。
そうなると、「はて、今回の要件は今後も同じような状況が発生するだろうか？」と考えるし、要件にからむステークホルダーと議論もするわけだが、だいたいにおいて不明確な場合がおおい。発生するような気もするし、気もしないし。
年月を経たアプリケーションには少なからずそういう仕様が散在し、幸運な場合は、古くからいる人だけがかろうじて覚えてる、不幸な場合は、担当者が退職しちゃってて誰も分からない、といった状況になる。そうなると開発速度は急激に下がり、障害のリスクは増える。いまいち要件が分からないからリファクタできないし、下手に消したりすると思いもよらないところから問題が上がってくる。
とはいっても、やらないわけにもいかないので、どうやって実装するかが考えどころとなる。ざっとレベル分けすると以下の４つになるだろうか
- レベル１： if文をソースに書き込む
- レベル２： YAMLか何かのconfigファイルに対象だけ外だしする
- レベル３： RDBのエンティティ・アトリビュート・バリューパターン（SQLアンチパターンにのってるやつね)となってるテーブルに持つ
- レベル４： 該当テーブルにカラムを追加して持つ
レベル３は明らかに筋が悪いが、割に見かけることがある。カラムをふやしてゴミになるのをためらった、といった背景だろう。
さて、どういった時にどのレベルを選択するのがよいだろうか。また、どうやってもゴミになるリスクはあるとして、どうすれば引き継げる仕様となるだろうか？コメント、ドキュメント、テスト、そういったもので地雷化は防げるだろうか。
といったことをうつらうつらと考えているところ。（つづく）