【リジェクトConライク】Re:cycle〜Kaigi on Rails 2025編〜 登壇資料

(株)タイミーの主催枠として発表したものです。

Transcript

1. 2025/10/07　甲斐 宏味 RSpec Style Guide VS 俺
2. 目次 • 自己紹介 • RSpec Style Guideとは • 規約と自分との戦い
3. 1 自己紹介
4. 自己紹介 名前：甲斐 宏味(かい ひろみ) 所属：エンジニアリング本部 プロダクトエンジニアリング部 職種：バックエンドエンジニア（Rails） 経歴：SE → (転職失敗して紆余曲折) → Webスタートアップ数社 → タイミー SNS：やってますが技術の話はしません 得意：ボトムアップアプローチ 苦手：リーダーシップ
5. 2 RSpec Style Guideとは
6. RSpec Style Guide - RSpecを記述するうえでの望ましいスタイルを記述したもの - いろんな組織が自分流をまとめているため、同名のガイドがいくつか存在する - https://github.com/willnet/rspec-style-guide - https://rspec.rubystyle.guide/ - https://github.com/rubocop/rspec-style-guide - 弊社はウィルネット版を推奨 - 以前の職場ではこれらをフォークしてアレンジしていた
7. 主な規約 - describeとcontextの使い分け - FactoryBotのデフォルト値をランダムにする - FactoryBotでbelongs_to以外の関連をデフォルトで作成しない - 日付をなるべく相対時間でテストする - beforeとlet(let!)の使い分け - 控えめなDRY - スコープの外でテストデータを定義しない - updateでデータを変更しない - allow_any_instance_ofを避ける
8. 主観的好き嫌い - describeとcontextの使い分け - FactoryBotのデフォルト値をランダムにする - FactoryBotでbelongs_to以外の関連をデフォルトで作成しない - 日付をなるべく相対時間でテストする - beforeとlet(let!)の使い分け - 控えめなDRY - スコープの外でテストデータを定義しない - updateでデータを変更しない - allow_any_instance_ofを避ける ☺ 🧐 🧐 🤕
 🫡
 🤯
 🤯
 🤯
 ☺

9. 遵守結構きつい！
10. 正直嫌い！
11. ここで冷静になろう
12. この好き嫌いに普遍性はあるのか？
13. 同僚に聞いてみた
14. 特に気にならない 設計に問題がある サイン 積極的に違反する のはよくない
15. 賛同ゼロ
16. 異常者の相手は疲れた
17. お前や
18. 3 規約と自分の戦い
19. 昔から「見やすい」「見づらい」という 主観的評価は同僚と意見が合わなかった
20. 考え方は変えられるが 感性を変えるのは難しい
21. 自分と他人の認知の違いは どこから発生しているのだろう
23. 認知負荷理論のキーワード - 長期記憶 - 永続的な記憶を保持する - 短期記憶 - 電話番号を一時的に暗記したりするときに使う - 領域の絶対的容量の個人差は少ない - 「チャンク」と呼ばれる意味的なまとまりの形成単位が知識・経験によって変わってくる - 既知の内容はより大きい単位でチャンクを形成できるので保持しやすくなる - ワーキングメモリ - 長期記憶・短期記憶を取り出して実際の思考を司る領域 - 研究によっては短期記憶と混同されていたりするらしい
24. 自分の短期記憶やワーキングメモリが 優れているから複雑なコードを書いて しまう可能性
25. 軽くテストしてみたが普通にダメだった 記憶能力が高いわけではない
26. 「チャンクの認識単位が違う」 ならもしかしたらあるかもしれない
27. 自分の担当ドメインは詳しいから チャンクの認識単位が広くなっている説
28. ドメインに詳しいと多くのコンテキスト を少ないチャンクに押し込めるから コードの記述量は少ないほうが多くの情 報を処理できる
29. でも読む人がそうとは限らない
30. ドメイン知識を活かして 少ない工数で書きたい VS 詳しくない人でも読みやすくしたい
31. さらにスタイルガイドを読み直してわ かったこと
32. 「describe 外にテストデータを置かない」は 許容パターンが存在してある （前職で同僚と争ったときの認識を更新でき てなかった）
33. そう考えると受け入れられないスタイルは 結構限定される
34. 工数に余裕がなくていつも焦っている 俺が単に自分本位なだけな気がしてきた
35. 結論があまりにもショボい 聴衆にもっと有意義な 情報を与えられないのか
36. 弊社のテストを片っ端から インプットしてみよう
37. まずはランダム抜き打ちチェック
38. 一つ一つ調べてみると案外逸脱してる
39. でもそこまで読むのは苦じゃない
40. 「読みづらいテスト」を探してみよう
41. おいDevin！ スタイルガイドの逸脱性が高いテスト 教えてくれ！
42. 肥大したモデルのテストは早々にワー キングメモリをはみ出してまともに全 容把握できなかった(メソッド単位な らなんとか追える)
43. 読みづらさと量が単純比例する感触
44. しかし全容が把握できないから設計の 細分化もできずに太り続ける という悪循環
45. 道のりは全然見えてないけど いずれ討伐したい
46. まとめ - 自分が抱いているスタイルガイドへの不満は「スムーズにテストが書けな い」というフラストレーションがもたらしている - さらにその原因を深堀りすると、スプリントの終盤で工数に余裕がない焦り であったり、ドメイン知識を利用してできるだけ記述量を減らしてチャンク を圧縮したいというインセンティブが働いていることかもしれない - 前職で喧嘩に近い議論をしたせいで冷静さを失っており、但し書きの内容を 利用していくことで適応の道筋がある程度見いだせる - スタイルガイド以前に記述量が多いテストはシンプルに読解が難しい。太っ たモデルは頑張って再設計して負債解消するのがよさそう
47. 結論
48. どう考えてもスタイルガイドの勝ち！
49. 色々考えてみたけど やっぱりショボかった
50. 落とされて正解だった 次はもっと有意義なアウトプットを 目指す
51. おしまい