昨日の論理削除Casual Talksの資料きた。よくわかる。
私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。
ここが本当に肝だと思う。
これまでに論理削除フラグを採用したプロジェクトにいた人や、少しこなれた情シス（非ユーザー）からはわりと簡単に「論理削除」という言葉が出がちだが、ユーザーにとってはその操作や処理はどんな意味があるのかを考えていないケースが殆どだと思う。
スライドにある通り、代替案の考慮なき提示は思考停止なわけだけど、削除=>論理削除という流れでイメージを想起する人は決して少なくないと思う。 特に実装や保守を通ってないとアンチパターンとしての負の側面を意識することが少ないだろうし、過去の案件で一つでも削除フラグを採用した経験があるとそれを定石としてしまうかもしれない。
自分が経験してきた業務システム系では「データは顧客の資産だから物理削除はもっての他」との意識が強い案件がいくつかあった。 これ自体は幅広く受容されている考え方だと思うし、実際に物理削除を行っているシステムはごくわずかしか聞かなかった。 とはいっても論理削除について削除フラグ以外の手段で向き合っている案件もほぼ聞かず、実際に自分のもとに降ってくる機会では全力で阻止した。
個人的には多くのエンジニアと同意見で削除フラグは滅すべきと思う。 実案件で削除の要件が出た時は以下の理由から@t_wadaさんの「案3.削除テーブルに移す」を選んだ。
- "削除"以外の状態として表現できない操作
- 対応が保守フェーズ
- 他の機能への影響が少なく、実装が最もシンプル
その後の保守を鑑みても本当に削除フラグを選ばなくて良かったと思う。 選んでいたらほぼ全ての機能でそのフラグを意識した開発を行わなければいけなくなっていたし、新たに参入する開発者に「削除フラグに注意してね」と言わなければならず、その度に悔しい思いをすることになっていた。
