こんにちは、今回のブログ担当・あべです！
ZEALSにジョインして早3ヶ月…会話広告fanpのサーバーサイドエンジニアとして、日々勉強しつつ楽しく働いています！！
さて、今回のテーマですが、以前サーバサイドエンジニアの中村さんが書いてくれた年末自由開発『Hack Days』で取り組んだテーマのうちの一つ、 「データの整合性を確保するため、validationを書きまくる」 について詳しく書きたいと思います。
なぜこのテーマに取り組んだのか
個々が自由に開発に取り組む中、なぜチームでこのテーマに取り組んだのか？ 前提として、開発において以下のような課題がありました。
- DBのテーブル構造に変更を加える際、本番環境で変更後のテーブル構造と不整合を起こす「 ゴミデータ 」が問題となっており、変更作業の負担になっている
- ゴミデータが発生する主な原因として、「 Railsのmodelのvalidationが不十分だったこと 」があり、これを解消する必要がある
validationを張りまくりゴミデータを発生させないため、12月初旬から少しずつvalidationの修正をしていこう！という話がチームであがり、「1人1日1modelずつ張る」ということを目標にしました。
しかし、日々の開発や対応に追われて思うように進まず進捗はいまひとつ。。
そこで、年末自由開発の時間を使ってvalidation修正にチームの力を一点集中！！一気に終わらせよう！ということになったのです。
何をやったのか
validationを見直し、誤ったvalidation・不適切なvalidationがあれば修正する、ということを全modelに対して行いました。
具体的には…
1. DBスキーマとmodelのvalidationとの整合性を取る
- DBスキーマの設定を確認し、その構造をmodelのvalidationとして書き起こしていく
2. DBスキーマで表現できないデータ構造があれば、validation側で追加実装する
- URLやメールアドレスなどDBスキーマで表現しきれないデータ構造を持つカラムについては、カスタムvalidationとして実装し、データの正確性を維持する
3. Factoryから正しい構造のデータが生成されるようにする
- 当該modelのFactoryを確認し、正しい構造のデータが生成されることを確認する
大変だったこと
まず大変だったことは、 「大量のタスクを短期間でこなす」 ということです。
今回の場合、タスク数＝model数となりますが、その数
125個！！！ （※後で数えました）
125、という数が多いか少ないかは人それぞれかと思いますが、前述の通り12月初旬に始めたものの進捗はいまひとつ…
未着手のもを大量に抱えたまま突入した年末開発で終わらせるには、チーム全員(6名)でひたすら潰すしかありませんでした。
数をこなすのももちろん大変ですが、そもそも書くvalidationを間違ってしまうとデータ周りで問題が発生してしまうため、素早くかつ正確にDBスキーマに沿って書くことが必要となります。
また、上記の内容に加え必要であれば新しくテストを書いたり、それに伴ったFactoryの改修やテストデータの変更など付随する作業も多々あります。
最初は「結構簡単かな？」と思ったのもつかの間、気がつけば最後の成果発表会ギリギリまで作業してなんとか間に合った、という感じでした。
テーマに取り組んだことでの学び
この取り組みを通して、全てのmodelにvalidationを張ることができただけでなく、多くの学びがありました！
PRレビューの過程でテストの方針などが共有された
例えば、下記のようなことが共有されました。
- enumテスト：enum定義におけるkeyやvalueの値までしっかりテストで検証する
- build と build_stubbed 使い分け： build_stubbedはテストが高速 なのでbuildと分けて積極的に使う
- build_stubbedを使うとassociation先のデータもDBにインサートされないため、少しですがテストが早くなります（塵も積もれば…ですね）
- subject定義：shouda-matchersはsubjectを書いた方が第三者から理解しやすい
議論されたことがチームで共有されることによりテストの質が保たれたり、他の人にわかりやすくなったりと、より良いコードに繋がります。
model周りの理解につながった
このテーマに取り組むにあたりただ闇雲に進めるのではなく、作業したmodelと関係のあるmodel、さらにそれに関係のあるmodelと順に辿って作業しました。
業務で自分が開発したコード周りはよく理解していても、そうでないところはあまり理解できてないかったりします（私の場合は特に、ですね..）。
改めてmodel同士の関係性の把握や理解につながり、業務効率がアップしました！
リファクタリングが進んだ
リレーションの多いモデルにvalidationを追加した際テストが大量に落ちることがあり、テストの実装がvalidationに沿っておらず間違って実装されていたために大幅な修正が必要となりました。
結果として正確でないコードを見つけ書き直すことができ、validationの追加も含め大幅にコードを改善することができました！
おわりに
日々の開発に追われるとなかなかこういった地味な作業はできずに後回しになってしまいがちです。
しかし今回の取り組みを通じて、古いコードが絶対ではないこと、コードを見直し改善していくことの大切さを改めて学びました。
初めての年末自由開発『Hack Days』、チーム全員でこのテーマを最後までやりきれたこと、とても良い経験になったと思います！
