継続的にRailsアプリを開発する上で早めにやっておきたいこと

https://gitlab.com/gitlab-org/gitlab/-/tree/master/rubocop/cop

https://postd.cc/how-dhh-organizes-his-rails-controllers

Transcript

1. STORES 株式会社 継続的にRailsアプリケーションを開発する 上で早めにやっておきたいこと morihirok
2. 自己紹介
3. 自己紹介 森弘 一茂 X: @_morihirok GitHub: morihirok STORES 株式会社 テクノロジー部門開発A本部 エンジニアリングマネージャー
4. 今日話すこと
5. STORES は熟成された Rails を複数開発・運用している ID基盤 事業者 基盤 顧客 基盤 分析 基盤
7. デカい！ 10年超え！
8. いろんな穴に落ちてきた
9. どんな Rails でも 共通して課題になること
10. 早めにやっておくと 複利で効いてくること 5選
11. 1. 継続的 bundle update
12. なぜライブラリ（gem）を最新にするのか • 一般的に、新しいバージョンのほうがパフォーマンスがよく、機能が多く、実 装が洗練されており、不具合が少なく、脆弱性が修正されている • 古いバージョンはサポートが切られており脆弱性の修正が行われないこともあ る
13. ライブラリ（gem）が最新に「なっていないと」どうなるのか • 古いバージョンを使い続けることで最新のバージョンとの乖離が広がり、アッ プデートの手間と難易度が上がる • いざ致命的な脆弱性が発見されたとき、新機能を使いたいとき、開発が止まり ライブラリアップデート大作戦が敢行される ◦ 脆弱性を見なかったことにする大作戦になることもあると聞いたことがある
14. ライブラリのアップデートは手間なので自動的に行いたい • 自動的かつ継続的にライブラリアップデートする仕組みは、早いうちに入れて おきたい ◦ Dependabot、Renovate など選択肢はいくつかある • STORES では自前で1日1回 bundle update して Pull Request を投げ、レ ビューをランダムアサインする GitHub Actions を用意し使っている ◦ その昔 Dependabot にまとめて bundle update してくれる機能がなかったので自前で作った という背景 • この辺りはチームの規模感や文化、状況に合わせて最もワークする方法を模索 する
15. STORES のとある Rails リポジトリの様子
16. STORES のとある Rails リポジトリの様子
17. 2. 継続的 RuboCop メンテ
18. 長期的にRailsリポジトリをメンテしていく上で、RuboCopは活用したい • いろんな人が開発に携わることになる可能性が高いので、一定コードの書きっ ぷりはRuboCopで統一していきたい ◦ 可読性が上がる、バグの温床を取り除ける • リポジトリ固有のルールもCustomCopで定義できる ◦ GitLab のリポジトリを眺めていると一種のプレイスタイルを感じる ◦ https://gitlab.com/gitlab-org/gitlab/-/tree/master/rubocop/cop • RuboCop を通じて生まれる議論はチームを底上げしていく（と思っている）
19. RuboCop あるある • 溜まりっぱなしの .rubocop_todo.yml • なぜか増える .rubocop_todo.yml
20. .rubocop_todo.yml を減らすのは手間なので自動的に行いたい • 自動的かつ継続的に .rubocop_todo.yml を減らす仕組みは、早いうちに入れ ておきたい • 規模が大きいRailsリポジトリになると .rubocop_todo.yml を生成するにも時 間がかかる • rubocop-todo-corrector を使えば GitHub Action で手軽に .rubocop_todo.yml をメンテする仕組みを入れられる ◦ https://github.com/r7kamura/rubocop-todo-corrector
21. STORES のとある Rails リポジトリの様子
22. 3. seed 整備
23. 長期的にRailsリポジトリをメンテしていく上で、seed は活用したい • 大きくなればなるほど、主要な機能をさらうだけでも時間がかかる • ちょっとした修正をするだけでも、実際に手元で動かすまでにいくつものス テップが必要になりがち • seed があればステップを省略でき、チーム全体の開発効率を上げられる
24. seed あるある • seed がない • 意気揚々と db:seed したら壊れている
25. seed は意外といろんな観点で生産性に効いてくる • 開発環境はだいたいよく壊れるし、だいたい全部消して作り直すと直る • seed がないがために手塩にかけて育てたテストデータに未練が残り、作り直 しの判断ができない • seed があれば何かおかしければさっさと作り直してすぐに開発を再開できる
26. seed を頑張ってメンテしよう • 初めの一歩はやるしかない、頑張って作り始める • CI で seed が壊れていないかテストしておくと便利 ◦ https://product.st.inc/entry/2021/08/18/124533 # spec/etc/seed_spec.rb require 'rails_helper' describe 'development seed ' do it 'success' do expect { Dir.glob('db/seeds/development/*.rb ').sort.each { | file| load(file) } }.not_to raise_error end end
27. 4. コードカバレッジのレポート整備
28. コードカバレッジとは • ソースコードがどれくらいテストされているか理解するのに役立つ指標 • Ruby には Coverage というライブラリがあり、これによってテストを動かし たときにコード実行の有無を測定できる ◦ テストによってコードが実行されていれば、それはテストによってカバーされていると考える • つまりカバレッジとはテストによってどれくらいのコードが実行されている か、その動作が担保されているか、というもの
29. コードカバレッジが測定できていることは重要 • カバレッジの高低が見えることによってとれる戦略が変わってくる • カバレッジが見えていないことによって、必要以上に保守的なソフトウェア開 発をしてしまいがち ◦ 特に長期的に開発されている Rails ではより保守的な引力が強く働きがち
30. SimpleCov はとりあえず入れておいてよい • CI でテスト実行時に SimpleCov が回るようにしておく ◦ https://github.com/simplecov-ruby/simplecov • 生成されたレポートをチームで閲覧できる状態にしておく • Codecov や Coveralls など、よりレポートを活用できるサービスもある
31. 5. DHH ルーティング
32. DHH ルーティングとは • https://postd.cc/how-dhh-organizes-his-rails-controllers ◦ コントローラはデフォルトのCRUDアクション index 、 show 、 new 、 edit 、 create 、 update 、 destroy のみを使う ◦ コントローラが元々持っているRESTアクションやデフォルトの5つの機能にはないメソッドを 付け加えたいと思ったら、いつだって新しいコントローラを作る ◦ 例えば InboxController#pendings を Inboxes::PendingsController#index にする
33. Controller あるある • 1クラスにいろんなアクションが書かれており巨大クラスになる • 見通しが悪くなり、どこに何があるかわからなくなる
34. DHH ルーティングに従うことのメリット • コントローラーを整理することができる ◦ Model が Fat になるのは一定仕方ない ◦ Controller が Fat になるのは避けられる • REST API におけるリソースについて意識を向けられ、よりよい設計を促す きっかけになる
35. おわり • 共通して起こりがちな Rails 課題にフォーカスしました • まだまだ話せていない課題がいっぱいあるので、懇親会で話しましょう
36. We Are Hireing!! STORES 採用 jobs.st.inc/engineer 詳細はこちらで検索
37. 福岡 Rubyist会議 04 ぜひお越しください！