flag

名前をせめて、flag_maskとかにしておけば良かった、と後悔。

SQLが悲惨なことになっているので、flag_maskの構造をやめて、独立したbooleanフラグを、ぞろぞろ列挙する構造に書き換えた。おかげで、SQLはすっきり。

ただし、コードレビューが大騒ぎ。flagで検索すると、単語単位で指定しても、システム内部のflagを含めて、かなり引っかかる。松尾くんとの会話を思い出した。

Productクラスの、「名称」はname、「コード」はcodeにした。これだと、productというインスタンスの名称は、product.name, コードは product.codeで引っ張ってこれる。「やめてください」と松尾くんに言われた。メンテが大変だ、と。「名称」はproduct_name, コードは product_codeにしてくれ、と。いや、それだと、呼び出すときに product.product_code, product.product_nameになって、あんまりコードが綺麗じゃないでしょ、と、僕の方から口答えしたんだけども、押し切られた感じで、product_code, product_nameという属性名にした。そっちはそれが大正解。

動作制御のフラグ関係は、僕がシンプルに flagという名称でつけたお陰で、検索すると他のクラスのflagまで一気に出てくる。ポリモーフィズムを使うつもりのフィールド名ならこれでOKだけれど、使わないなら、これは絶対に避けるべきだった。

flagという単語以外に、hidden_flagとか、接頭語をつけたflagもあるから、単語単位を指定して検索しても、とにかく、djangoシステムプログラムのflagまで出てきてしまって、「全体」をターゲットにしてのflag検索が、大変なことになってしまった・・・波及箇所を調べる訳だから、検索範囲を絞り込む訳にはいかないし。

orz

はまった。ドツボった。flag_maskなら、相当に楽だったのに。

松尾くん、さすがに場数を踏んでるよなぁ。実戦の勘が、僕は働かなくなってた。
・・・気を取り直して・・・とにかく、全部丁寧に目を通すしかない、ですね。

他山の石にして下さいませ。