この記事は、Crieitのアドベントカレンダー、なんでもの5日目の記事です。
こんにちは、Yumihikiです。今回は私が過去に行ったバグのお話を書ける範囲で書いてみようと思います。
といった感じです。
事件が発覚したのは私がお客様先で働き始めてちょうど100日後(目?)のことでした。
とあるデータ群の登録状態がおかしなことになっているらしく、私が直前にその社内システムの改修をしていたこともあり調査を依頼されました。
ソースには私以外にも他の方が改修を行っており、他の方が改修した内容がおそらく原因だろうと言われながら調査を行いました。
他の方のソースを見つつ、おかしそうなところが無いか調べていくも見つからず...
調査すること2日目、バグの理由が分かりました。
そう、この冒頭にもあるように原因は私でした。
当時のバグ発見後のツイートが下記です。
バグを埋め込んだことが発覚して、お客様先へいる時はダメージ少なかったけど家に帰ったらダメージがどっと出てきた…今日は早く寝よう… 明日修正頑張る…
— Yumihiki (@nibupro) July 1, 2020
ダメージは少なかったと言っていますが見つけた瞬間には冷や汗が止まらず、動揺も重なりうまく説明も出来ないので先輩エンジニアにコードを見てもらいながら現象についてプロパーの方へ一緒に説明してもらいました。
どなたからも怒られることはなく、優しさが救いでした。。。
(お客様先のシステムでもあるので、かなりボカシ気味ですみません)
原因:既存のロジックがどのように動いているか把握していなかったこと。
バグを埋め込むきっかけとなった改修の時に、かなり実装で悩んでおり自社の先輩に相談したところ
「この変数を書き換えてやればやりたいことが出来るよ」とアドバイスをもらいました。
本来、その変数が他にも使われていないかを影響調査する必要があったのですがその過程をすっ飛ばしていました。
今振り返ると、それは当然バグも入り込むわ... と思います。
また、テストも行っていましたが想定外の機能に影響しており、検出することは出来ませんでした。
理由:焦っていたから。
改修時に工数はこのくらいの期間ね、と言われていたことから「納期を守って成果を出さないと」という焦りがありました。
全然リスケは可能な改修だったのですが、まともな判断が出来ていなかったのだなと後から振り返ってみて思いました。
焦っていたとしても調査は怠らないようにすることで、次から防ぐことが出来ると考えています。
バグを埋め込んだ当時は本当にしんどかったです。この結果が原因でクビになったらどうしよう、とかずっと考えていましたが
そんなことはなく、今もお客様先で働かせてもらっています。
また、Twitter上でバグ埋め込んだ話を投稿したところ、フォロワーの方、大学の先輩からも励ましのコメントをもらえてとても温かったです。
今はまた新たに調査を頼まれて、調査を行っている最中であります。
Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。
また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは?
コメント