前回原因が分からなかったと書いたバグの根本原因が判明した。
半日かけて原因解明して、結局コードパスに抜けがあって何かの原因でそこを通るようになってしまったのが不具合の原因と分かったんだが、抜けはふさげばいいとしても、何で今まで不発だったその地雷が急に炸裂するようになったのかが分からないままなんだよな。
何か奥歯に小骨が挟まったかのような不快感。
そのうちまた別の地雷を踏みそうなのが怖い。
結局前回の危惧が当たって、同じ根本原因によるバグが他にも起こったのだ。
まあそのおかげで根本原因が分かったので、悪いことばかりでもないのだが。
結局根本原因となっていたのは、システム全体の設計のまずさだった。
このシステムはユーザーアカウントを登録する際に、一意のIDを振る必要があるのだが、入力チェックがざるでIDに空文字を入力できてしまうのだ。
そしてこのIDが空文字のアカウントこそが悪さをしている原因だった。
というよりも、データの整合性に依存するシステムながらチェックがざるだというのがそもそも駄目なんだが。
まずシステムのアカウント情報の取得の仕方が「何でそんな訳分からん処理になってんだ」と言いたいくらいおかしなやり方になっていた。
DBにIDが空文字のアカウントが存在すると、ログインをすっ飛ばしてエラー画面を表示する素敵仕様。
なぜかログイン時や特定のシステムを使用しようとしたときに、まずID空文字でアカウント情報をデータベースに取得しに行き、取っちゃいけないアカウント情報を取ったりエラーを吐いたりするのだ。
何その意味不明な処理。マジありえん。
コードをしらみつぶしにしてみたが、そもそもIDが空文字のアカウントの存在なんて、欠片も考慮されていない設計だったようだ。
他にもこのシステムはデータベースの扱いがなっておらず、探すとDBアクセス部位のコードに謎なコードがぞろぞろと。
例えばシーケンス使って一意のID作らせておきながら、データ登録時でなくて登録ページ表示時にIDとって来るとか意味不明な処理をしていたり。
おかげでページの更新のたびにIDが上がるから、データを削除したわけでもないのに連番になってない。
一体どういう設計からコードを起こせばこうなるのやら。
ヤバイシステムは大抵設計レベルから問題を抱えている。
前回半分冗談で「他所の会社が取引先に納めたシステムの保守で、おまけに作った会社がもう存在しないという、うかつに弄れない地雷原だったりする。」と書いたのだが、冗談抜きで本当に地雷処理作業にかからにゃならんようだ。
