Web現場Meetup#3 Ruby on Rails: the Good Parts 2018

https://pixta-inc.connpass.com/event/80223/ にて発表した内容

Transcript

1. Ruby on Rails: the Good Parts 2018 ピクスタ株式会社 プラットフォーム本部 開発部 エンジニア 大村 直人 (twitter: @urakawa) Web現場meetup #3
2. こんにちは！
3. みなさんはじめまして。ピクスタの大村です。 2016 年 12 月 ピクスタ(株) 入社 2017 年 6 月より現職(fotowa 担当)
4. fotowa のご紹介 写真を撮影したいユーザーと、登 録フォトグラファーをマッチング し、 人生のイベントや大切なひと時を プロの手でハイクオリティな写真 に残す 「出張撮影」プラットフォームサー ビスです。 https://fotowa.com
5. よろしく お願いします！
6. Ruby on Rails: the Good Parts 2018
7. Ruby on Rails: the Good Parts 2018
8. 大きくなっていく Railsアプリケーションを 改善し続けるための取捨選択 〜fotowa の事例 2018〜
9. • Rails 5.1 / 5.2 の新機能の話 （Active Storage は早く使ってみたいですね） • フロントエンド（JavaScript）の話 • 教育や組織論の話 話さないことリスト
10. 年末にブログを書きました http://texta.pixta.jp/entry/2017/12/07/113000
11. https://qiita.com/urakawa/items/3d7777e6734cb5c15bd1
12. fotowa のサービス規模 • 月間撮影件数(最大実績) 1,800 over • 2017 年間撮影件数 YoY +600% over • 総登録フォトグラファー 500 over オープンから2年が経ちました 一定の規模のビジネスになってきたが、 まだまだサービスとして成長・拡大が期待されるフェーズ
13. fotowa のプロジェクト規模 • プロダクトオーナー 1 • エンジニア 4 • デザイナー 3 • 運用・ビジネスサイド担当 5 + α オープンから2年が経ちました 一定の規模のビジネスになってきたが、 まだまだサービスとして成長・拡大が期待されるフェーズ
14. fotowa のシステム規模 • Ruby (バックエンドのアプリケーション) 8000行 • Ruby (テストコード) 4500行 • DB マイグレーションファイル 1000行 • ビューテンプレート 13000行 オープンから2年が経ちました 一定の規模のビジネスになってきたが、 まだまだサービスとして成長・拡大が期待されるフェーズ
15. fotowa 開発チームの課題 • ステージの変化 ◦ 早いリリースから、安定した運用と継続的な拡張へ • 拡大していく規模 • メンバーの入れ替わり → ノウハウの保持と規律の確保
16. Rails の生産性の意味 Rails Doctorine ( http://rubyonrails.org/doctrine/) より (邦訳 http://postd.cc/rails-doctrine/) ひとりで完結して統合システムを記述することができる。 → 実装開始からサービス開始までの速度重視 ＊一人の時は、知識のばらつきが問題にならない It is this focus on empowering the individual that points to the integrated system. (統合システムに目を向けるのは、個人に能力を与えることに重点を置いているからで す。)
17. チームで書くコードの原則 • 書く時間よりも読む時間の方が長い • 一貫性を保とうとする姿勢 同じ気持ちで読み、そして書けるチームの生産性が高い ルール/ガイドラインに従う → 前提：ルール/ガイドラインを作る （ベストは2人目が入る前に）
18. ルール/ガイドラインの目的 天才(一人目)が書くコードをブラックボックスにしない
19. fotowa チームのガイドライン(抜粋)
20. 大原則 • Rails のレールには乗る ◦ CoC (設定より規約) ◦ ActiveRecord ◦ コントローラの基本7アクション • 機能を「あるから使う」は NG ◦ DHH の気持ちになって適切な使い所を考える
21. 大原則 • オブジェクト指向設計に真面目に取り組む ◦ カプセル化と継承とポリモーフィズム ◦ OOP デザインパターンを学ぶ ◦ データの流れを簡潔にする • 読んでビジネス要件を理解できるコード
22. 推奨 (1) composed_of http://api.rubyonrails.org/classes/ActiveRecord/Aggregations/ClassMethods.html より ActiveRecord の属性をValueObjectとして表す
23. Value Object とは？ 「シンプルで小型なオブジェクト」で int や string, datetime などを ラップして、意味と振る舞いを与える
24. 推奨 (2) サブリソースのコントローラ http://postd.cc/how-dhh-organizes-his-rails-controllers/ より 一つのコントローラにアクションが大量にあると、 役割がわかりづらくなっていく
25. 推奨 (3) イミュータブルデータモデル UPDATE を最小限にしてモデルの複雑性を下げる 「更新されるのはどこか？」を設計上明確にする
26. 撮影案件周辺のER図抜粋
27. 推奨 (4) 極小 Controller、大きめ Model 1. サブリソースのコントローラを積極利用(前述)で、 一つの Controller のコードで、最大130行 2. Model の責務を適切に分担するオブジェクト群を 用意する
29. 推奨 (4-a) ViewObject ビューに関するロジックを ActiveRecord から分離する draper gem を利用して実装
30. 推奨 (4-b) FormObject フォーム入力のデータをロジックに渡す処理を分離する
31. 推奨 (4-c) FinderObject・QueryObject オブジェクトのライフサイクル(Read系)を分離する
32. 推奨 (4-d) ServiceObject アプリケーションの都合を Controller / Model から分離する
33. 非推奨 (1) before_action, after_action • 本当に共通処理ですか？ • クラス変数の代入なんかしたら見通し悪くないですか？ 「ログインしてなかったらログインフォームにリダイレクト」など、共 通のフィルタリングにのみ使う Rails 3 までは、「before_filter」という名前だった
34. 非推奨 (2) ActiveRecord コールバック • 非同期処理でも Observer パターンでもない • AやってBやって…って処理の流れを追えますか？ ビジネスとして必然性のある処理はコールバックに書かない 使っていい例： • アプリケーションログを出力 • キャッシュをクリア
35. 非推奨 (3) ViewHelper, ActiveSupport::Concern かなり具体的で全体に影響する共通実装のみ 現在、 fotowa では helper 合計 120 行、concerns 合計 25行
36. 非推奨 (4) accepts_nested_attributes_for 通常、複数オブジェクトをフォームで取り扱う場合、FormObject を利用した方が柔軟性が高い 「このクラス経由でしか、この関連にはアクセスしない」という場合 のみ使う 常に一つのかたまりとして扱う
37. 使用例
38. 非推奨 (5) メタプログラミング メタプログラミングをアプリケーション内部に持ち込まない (あっという間に読めなくなる) メタプログラミングの手法はライブラリに隠蔽し、アプリケーション はその成果としての DSL を利用する (DSL の仕様については必ずドキュメントを残す)
39. fotowa アプリケーション内の唯一それっぽいコード
40. まとめ：取り組みの目的 ノウハウの保持と規律の確保 • 「チームのコード」と「自分のコード」を同一にする • 共有と共通理解をチームの生産性向上の糧とする • Rails や周辺の変化への対応をより簡単にする
42. ご静聴 ありがとう ございました！
43. Ruby on Rails: the Good Parts 2018 ピクスタ株式会社 プラットフォーム本部 開発部 エンジニア 大村 直人 (twitter: @urakawa) Web現場meetup #3 終