新卒エンジニアがもらった今週のコードレビュー(2、やらかしあるよ)

やらしかした！！

今週はやらかしました！！その中で最低限できていたことも振り返りつつ、絶対に次に活かすことが決まったのでここに決意と共に反省していこうと思います。

ことが起こるまで

今回自分のプルリクエストでは、

1. DBの、あるカラムのデータの形式を変更する
2. この変更に合わせて、関連のあるアプリケーション側の整合性が担保されるように修正を行う

ということを行っていました。変更するカラムはアプリケーションでもメインと言えるテーブルで、そのほぼ全てのデータのとあるカラムを更新しなきゃいけないという結構怖い作業でした。実装の仕方としては、処理全体にトランザクションを貼り、処理全体にトランザクションを貼り（タイポじゃないです。大事なことなので２回言いました）、5000件ごとにバルクアップデートしていくと言うものでした。
そして、DBに変更が影響しそうな部分については、パイプラインの順序を考慮せずに行いました。つまり、パイプラインの順序を考慮せずに行ったのです！！（小泉構文）

エンジニア界の尾田栄一郎、怒涛の伏線回収

物語は佳境に入っていきます。

トランザクションを張る範囲が大きすぎてタイムアウト

リリース作業中、まずは「トランザクションを張る範囲が大きすぎてタイムアウトする」と言うことが起こりました。ちゃっかりレビューは通っており本番反映を進めていたのですが、テスト環境とは比べ物にならん量のデータの本番環境ではトランザクションの範囲が大きすぎてタイムアウトを起こしてしまいました、、
ここでは良かったこともあります。それはトランザクションを張っていたことです（！？）。トランザクションとは、関連する処理をまとめて行い、もし途中で失敗したらロールバック（＝それまで更新したものを元に戻すこと）して何事もなかったかのようにすることです。バックエンドのことなんて何にもわかっていないのにデータ指向アプリケーションデザインを一丁前によんでいたところ、ちょうどトランザクションについての記述があり、「これは使わなければ！！」と思い、付け焼き刃で貼っていたのです。おかけで失敗はしたけどダメージは少なく済みました。
この時、高校生の頃に初めてコンビニでバイトを始めてレジのやり方を教わっていた時に、「最初はいろんなボタンを覚えるんじゃなくて、キャンセルの仕方を覚えた方がいい」と言われたことを思い出しました。ミスった時に完璧にキャンセルできると、焦らずにあってるかわからんボタンをぽちぽち押せるからです。まさか高校生からトランザクションを体で行っていたなんて、、！！

パイプラインの順序を考慮していなかったためテストで落ちる

なんとかマイグレーションは修正（してもらった、いつかできるようになりたい）終わったものの、今度はテストで落ちました。楽しませてくれるじゃねか、、（ごめんなさい）
理由は、先のミスですでにDBの形式が変更された後落ちた→コードはデプロイされていないので整合性がとれずテストが通らなかったと言うのが原因でした、、
修正パッチ（＝ソフトのおかしい部分を直すために用意された、後付けのプログラムのことらしい、始めて知った）を当ててもらい（自分でやれ、うるさいできない）なんとかリリースとなりました、、

いつか海賊王になるために必要だった失敗と言えるように

実は本番環境と言っていましたが、私のところでは環境が３つあり、書いていたことは1つ目から2つ目に反映している際に起こったことなので厳密には本番ではありません。胸を撫で下ろす反面、ブラックサッカー部所属時代に寝坊した時くらい焦りました、、

学んだこと

もっとデータベースの気持ちを考えてあげないといけないと思った。確かに、こっちの都合でまとめて何万件覚えさせるなんて全然ブラックサッカー部所属時代を反面教師にできていない、、トランザクションを張る範囲に関してもっと考慮しようと思いました。
テストで落ちてしまったことは仕方ないことかなとも思いつつ、高校時代の「最初はいろんなボタンを覚えるんじゃなくて、キャンセルの仕方を覚えた方がいい」と言う金言の元、すんなり修正パッチが当てられるくらい勉強していきたいなと思いました。