カッパでも分かるiOSアプリゲーム開発

カッパがひたすらゲーム制作に関することを書くブログです。Railsに関するTipsもたまにまとめてます。

【Rails】belongs_to に dependent: :destroy を指定して障害を起こしてしまった

スポンサードリンク

パーフェクトRuby on Rails

パーフェクトRuby on Rails

自分のコードが原因で障害が起きると世界に対して非常に申し訳ない気持になる。
なんで自分はあんなコードを書いたんだ……とコードを書いていた時の自分を呪う。
今後の再発防止のためにも記録。

なぜかbelongs_to にも dependent: :destroy を指定していた

has_many の関連で dependent: destroy を指定する事はよくある。親元が消えれば子も消えるというわけだ。

一方で、 belongs_to の関連で dependent: destroy を指定する事なんて殆どない。
今回はこれのせいで、子のデータを一つ消しただけで親のデータも消えてしまい、障害が起きてしまった。

ごく稀にレアケースで belons_to に dependent: destroy をつけるような仕様の時もあるかもしれないが
今後は直感的に belongs_to に dependent: destroy があったら疑う癖を付けたいと思う。

なぜ自分はそんなコードを書いた?

has_many 関連のコードをコピーペーストして書いたからだろうか。
クラス名とかを typing するのは typo に繋がるし、コピペでコーディングする事自体は悪い事ではないが……。

「少なくとも子が削除されたら親も一緒に削除されないと」と意識して書いた訳ではない。
自分の書いたコードをもっと客観的な目線でチェックする癖をつけなければ。

ちなみに該当箇所が二箇所もあったのが非常に情けない。

なぜテストで気付かなかった?

一番の問題はここだと思う。
どんな悪しきコードを書いてもテストさえちゃんとしていれば障害は未然に防げる。
今回は子のデータ削除というテストを怠っていた。

大事なのはここから

深く落ち込む事も大事だけれど、それで先方が喜ぶ訳でも無い。
自分がすべきは次の仕事で良いコードを書いて挽回する事だと思う。

こんな時にベテランならすぐに気持を切り替えるんだろうか。
自分は一度ミスしただけでクヨクヨと引きずってしまう傾向がある。

とにかく次の仕事ではテストを入念にする事を念頭において作業しようと思う。

気持を切り替えねば

自分に言ってしまうのは甘えになるが、
もし同様のミスをした同期がいたとしたら

「大量のコードを書けば必ずバグが生じる可能性は高まる。チャレンジした証なのだから結果は残念だったけど悪い事じゃない」

と励ますだろう。
悔しさを忘れずクヨクヨしないメンタルコントロールする術を身に付けたい。