どうもmizukiです。先日VBAの保守が辛いと嘆いてましたが『delete_flg』が原因でバグを発生させてしまい必死のリカバーをしました。
引き継いだシステムでそもそも改修予算がないのでフィールドの削除などはほぼ不可能ですが、今後新規でシステムを構築する際に同じ過ちを繰り返さないように、削除フラグについて考えました。
削除フラグについて考える
まずは今回のバグになった原因のテーブルを紹介します。別会社から引き継いだシステムです（重要）引継ぎ書、設計書何もありませんでした（血涙）
今回バグを放り込んだテーブル構造
良くある1対多のテーブルです。簡略化していますが下の図のような構成です。
このテーブル以外にもいたる所に『delete_flg』が存在しています。
なぜバグが発生したのか
単純に小テーブルの削除フラグをWHEREに入れ忘れたのが原因でした。入れ忘れにより子テーブル側で管理している金額が削除しても反映されていました。
どうやったら防げたか
①テストをしっかりとやる
②そもそも設計段階で削除フラグを無くす
①のテストをしっかりと行い品質を保つのは基本ですが諸事情により工数貰えなさすぎてモンキーテストから本番環境に投げてます。（システムが無駄なコスト扱い）
なので②の案について考えます。まずは削除フラグのデメリットを考えてみます。
削除フラグを設定するデメリット
WHERE句で毎回指定しなければならない
削除した行のデータはデータ自体は存在するが実際には無き物として扱わなければならないので『WHERE句で毎回削除フラグを指定する』必要があり、うっかりそれを忘れると今回のようなバグになります。また、テストケースにも入れなければならないのでシステムの規模が大きくなると煩雑になってしまいます、
（例）削除フラグを指定しているテーブルが10個ある。
そのテーブルを呼び出すテーブルがあれば最低10回はWHEREで指定する。そしてテストもWHEREの条件が動いているかを確認する為最低10必要になります。
もし、削除フラグを使っているテーブルが半分の5個であれば、後ろの部分も半分になり大分作業が減ります。
僕が考えた感じではこれが唯一にして致命的なデメリットでした。
削除フラグを設定するメリット
メリットは論理削除が行えユーザーがデータをもとに戻せる事のみです。
削除したデータを戻すことができる
主にユーザーにとってうれしい機能だと思います。間違って消してしまったデータを戻せるのは便利です。
保守側の視点では「ユーザーからのデータ削除復旧問い合わせ」が減るので仕事が減ります。（データ間違って消したんだけど戻せない」的な奴です。）
まとめ
ユーザーの論理削除が行える利便性を取るのか、システム開発のスピードを取るのかのトレードオフになります。
「とりあえずテーブル作ったから削除フラグ作っておこう」は絶対に止めて、必要なテーブルにのみ設定するようにしたいです。
僕の場合は「ユーザーが誤って消してしまった際に復旧が面倒なテーブル」にのみ、設定を行うようにしています。工数無い場合は全部物理削除で実装してDBのバックアップ取るスタイル。
ちなみに『delete_flg』では直感的では無く解りにくいので『is_deleted』を使うのが良いです。
終わりに
最後に保守中のシステムのヤバイ地雷を紹介します。今後システム設計する場面では思い出して回避したい。
現在システムのあるデータベースのフィールドには「業務状態を表すフラグが7つほど」存在しています。各業務フローを通過する度に次々とそれらのフラグがTRUEに変わっていきます。そして、業務フローが変更される度にフィールドを追加したみたいです。（引き継いだ際に調査をしてコードを見た感じそれっぽい）
なんとか各フラグが立つ状況は把握したのですが、フラグによって画面遷移時にエラー吐いてたりするので良くわかっていません。
もうすでになりつつありますが。あと何年かしたら誰も読めないコードになります。
設計時にフラグじゃなくてステータスで管理したらまだ読みやすかった（戒め）
今までの経験からシステムを引き継いで改修・保守するのは死ぬほどきついので今後は止めたいです。引継ぎ系の案件は今までまともな思い出がありません。ドキュメントがまともに揃っていた事は一度も無いです。大抵存在しないか、あっても情報が古い地雷文書になっていました。他の会社の人はどうなのか気になる…。とりあえず削除フラグのご利用は計画的に！
ここまで読んで頂いてありがとうございます。明日も頑張りましょう！
コメント