_Ruby失敗談_Zeals編.pdf

Zealsで実際に起きた事件です

Transcript

1. Zealsで実際に起きた事件 【Rails失敗談】 テクノロジー開発部 小寺 京佑
2. • 自己紹介 • 実際あった失敗談 • まとめ Agenda
3. 自己紹介
4. ZEALS Engineer Rubyエンジニア 小寺 京佑 ：kodera123 ：kody015 ：nil ：kodera123 - DMM Infratop (旧Infratop) - Zeals - Ruby - JS（React, Vue）
5. rubocop disable減らない問題
6. rubocop disable の箇所が増えるばかり - rubocop.yml はほぼデフォルト - 急ぎながらもコードベースを 綺麗に保ちたかった - 「後でやります！」が免罪符 - スケジュール的に、直すリソー スを考慮してなかった
8. 対応策 - 運用ルールを決め、チームで共通認識をとった
9. 放置 TODO/FIXME 問題
10. 大量のTODO/FIXME - 先ほどと同じだが回収されない - もう辞めてしまった人が残したものがある - 2年前に書かれた化石もある
11. 大量のTODO/FIXME
12. 対応策 - 優先度が上がらず未対応... - rubocopの時と同様運用ルールを決め、チームで共 通認識をとりたい
13. DRYすぎたspec 問題
14. DRY にしすぎて可読性が下がってしまった https://qiita.com/jnchito/items/eb3cfa9f7db752dcb796
15. - テストデータで何が作られているのかが理解に 時間かかる - expect で何を期待してるのかが予測しにくく なる
16. - 対象のコードの仕様がひと目でわかること （仕様書になっていること） - 確実にバグを検出できること
17. ランダム落ちspec
18. rspec がランダムで落ちてしまう - 単純にテストデータを作り間違えていた - CI落ちるので急いでる時にめんどい - gem faker を使用していて安心していた - Faker::Pokemon.name - ポケモン 53種類しかいない - 2%くらいの確率で落ちる
19. 対策 - factory の seaquense 使って連番するなりユニー ク制約があるテストデータを作る時には気をつけ る
20. テストカバレッジの罠
21. 94 ~ 95%までカバレッジあげたが 普通にリグレッション発生する - コントローラーのテストばっかり書いていた - response status - render template - くらいしかテストできない - 異常系のテストをそんなに書いてなかった
22. 対策 - 費用対効果の高いテストを書くことを気をつける - ユニットテストを書くように進行中 - テストデータを作りやすい - テストケースも想定しやすい - 数字に騙されない
23. いたずらに増えるサービスクラス
24. とりあえず複雑な処理を サービスクラスに押し込んでしまった
25. 対策 - ドメイン駆動設計を参考にリファクタリングの方 針を立て実行中 ※あくまで草案なので変更の可能性はあります
26. rollbar鳴りすぎて狼少年化
27. 150 ~ 250 件くらい溜まってしまった - 誰も見なくなる - 重大なインシデント埋もれる 【原因】 - 例外設計がずさんだった - validation error も rollbar 鳴らしてた - js 側の error とか
28. 対応策 - 例外設計ちゃんとやりましょう - 何でもかんでも rescue しない - システムのエラーなのかユーザーのエラーなのか適 切に伝えてあげる - https://qiita.com/jnchito/items/3ef95ea144ed 15df3637
29. query クラス（じゃなくても） に直書きSQL
30. メンテに恐怖感覚える - 100行くらい - group concat とか色々使われ てて読むの億劫 -> 先ほどのリファクタリング計 画に合わせて直していく予定
31. rake タスク でメモリ食いつぶした
32. each で バッチ実行時にメモリ食いつぶした - 以下の記事の通りARのアンチパターンハマってた https://blog.toshimaru.net/rdm2018-active-re cord-anti-patterns/ - 50万レコードの処理にeachを使ってメモリ食いつ ぶし
33. 対策 - each -> find_each を使うようにする - update -> update_all を使うようにする - validation skip するので気をつける
34. まとめ
35. まとめ • 後でやらない or スケジュール決める • 失敗した後の対策が大事 • 外部の方にレビューしてもらうのも大事
36. LET'S START NEXT INDUSTRIAL REVOLUTION WITH OUR FLYING SHUTTLE
37. Thank you!!