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

by morihirok

Slide 1

Slide 1 text

STORES 株式会社継続的にRailsアプリケーションを開発する上で早めにやっておきたいこと morihirok

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

自己紹介森弘一茂 X: @_morihirok GitHub: morihirok STORES 株式会社テクノロジー部門開発A本部エンジニアリングマネージャー

Slide 4

Slide 4 text

今日話すこと

Slide 5

Slide 5 text

STORES は熟成された Rails を複数開発・運用している ID基盤事業者基盤顧客基盤分析基盤

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

デカい！ 10年超え！

Slide 8

Slide 8 text

いろんな穴に落ちてきた

Slide 9

Slide 9 text

どんな Rails でも共通して課題になること

Slide 10

Slide 10 text

早めにやっておくと複利で効いてくること 5選

Slide 11

Slide 11 text

1. 継続的 bundle update

Slide 12

Slide 12 text

なぜライブラリ（gem）を最新にするのか ● 一般的に、新しいバージョンのほうがパフォーマンスがよく、機能が多く、実装が洗練されており、不具合が少なく、脆弱性が修正されている ● 古いバージョンはサポートが切られており脆弱性の修正が行われないこともある

Slide 13

Slide 13 text

ライブラリ（gem）が最新に「なっていないと」どうなるのか ● 古いバージョンを使い続けることで最新のバージョンとの乖離が広がり、アップデートの手間と難易度が上がる ● いざ致命的な脆弱性が発見されたとき、新機能を使いたいとき、開発が止まりライブラリアップデート大作戦が敢行される ○ 脆弱性を見なかったことにする大作戦になることもあると聞いたことがある

Slide 14

Slide 14 text

ライブラリのアップデートは手間なので自動的に行いたい ● 自動的かつ継続的にライブラリアップデートする仕組みは、早いうちに入れておきたい ○ Dependabot、Renovate など選択肢はいくつかある ● STORES では自前で1日1回 bundle update して Pull Request を投げ、レビューをランダムアサインする GitHub Actions を用意し使っている ○ その昔 Dependabot にまとめて bundle update してくれる機能がなかったので自前で作ったという背景 ● この辺りはチームの規模感や文化、状況に合わせて最もワークする方法を模索する

Slide 15

Slide 15 text

STORES のとある Rails リポジトリの様子

Slide 16

Slide 16 text

STORES のとある Rails リポジトリの様子

Slide 17

Slide 17 text

2. 継続的 RuboCop メンテ

Slide 18

Slide 18 text

長期的にRailsリポジトリをメンテしていく上で、RuboCopは活用したい ● いろんな人が開発に携わることになる可能性が高いので、一定コードの書きっぷりはRuboCopで統一していきたい ○ 可読性が上がる、バグの温床を取り除ける ● リポジトリ固有のルールもCustomCopで定義できる ○ GitLab のリポジトリを眺めていると一種のプレイスタイルを感じる ○ https://gitlab.com/gitlab-org/gitlab/-/tree/master/rubocop/cop ● RuboCop を通じて生まれる議論はチームを底上げしていく（と思っている）

Slide 19

Slide 19 text

RuboCop あるある ● 溜まりっぱなしの .rubocop_todo.yml ● なぜか増える .rubocop_todo.yml

Slide 20

Slide 20 text

.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

Slide 21

Slide 21 text

STORES のとある Rails リポジトリの様子

Slide 22

Slide 22 text

3. seed 整備

Slide 23

Slide 23 text

長期的にRailsリポジトリをメンテしていく上で、seed は活用したい ● 大きくなればなるほど、主要な機能をさらうだけでも時間がかかる ● ちょっとした修正をするだけでも、実際に手元で動かすまでにいくつものステップが必要になりがち ● seed があればステップを省略でき、チーム全体の開発効率を上げられる

Slide 24

Slide 24 text

seed あるある ● seed がない ● 意気揚々と db:seed したら壊れている

Slide 25

Slide 25 text

seed は意外といろんな観点で生産性に効いてくる ● 開発環境はだいたいよく壊れるし、だいたい全部消して作り直すと直る ● seed がないがために手塩にかけて育てたテストデータに未練が残り、作り直しの判断ができない ● seed があれば何かおかしければさっさと作り直してすぐに開発を再開できる

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

4. コードカバレッジのレポート整備

Slide 28

Slide 28 text

コードカバレッジとは ● ソースコードがどれくらいテストされているか理解するのに役立つ指標 ● Ruby には Coverage というライブラリがあり、これによってテストを動かしたときにコード実行の有無を測定できる ○ テストによってコードが実行されていれば、それはテストによってカバーされていると考える ● つまりカバレッジとはテストによってどれくらいのコードが実行されているか、その動作が担保されているか、というもの

Slide 29

Slide 29 text

コードカバレッジが測定できていることは重要 ● カバレッジの高低が見えることによってとれる戦略が変わってくる ● カバレッジが見えていないことによって、必要以上に保守的なソフトウェア開発をしてしまいがち ○ 特に長期的に開発されている Rails ではより保守的な引力が強く働きがち

Slide 30

Slide 30 text

SimpleCov はとりあえず入れておいてよい ● CI でテスト実行時に SimpleCov が回るようにしておく ○ https://github.com/simplecov-ruby/simplecov ● 生成されたレポートをチームで閲覧できる状態にしておく ● Codecov や Coveralls など、よりレポートを活用できるサービスもある

Slide 31

Slide 31 text

5. DHH ルーティング

Slide 32

Slide 32 text

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 にする

Slide 33

Slide 33 text

Controller あるある ● 1クラスにいろんなアクションが書かれており巨大クラスになる ● 見通しが悪くなり、どこに何があるかわからなくなる

Slide 34

Slide 34 text

DHH ルーティングに従うことのメリット ● コントローラーを整理することができる ○ Model が Fat になるのは一定仕方ない ○ Controller が Fat になるのは避けられる ● REST API におけるリソースについて意識を向けられ、よりよい設計を促すきっかけになる

Slide 35

Slide 35 text

おわり ● 共通して起こりがちな Rails 課題にフォーカスしました ● まだまだ話せていない課題がいっぱいあるので、懇親会で話しましょう

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text