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