Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
今年 会社でのレビューで話した事
Search
Ryz310
December 13, 2019
Programming
2
1.9k
今年 会社でのレビューで話した事
レビューでクラスの設計がムズいという声を受けて幾つか社内で解説をしたのですが、今日はその中から一部を抜粋して持ってきました。
Ryz310
December 13, 2019
Tweet
Share
More Decks by Ryz310
See All by Ryz310
Redis::Objects で遊んでみよう
ryz310
0
1k
My API Client
ryz310
0
170
MyApiClient
ryz310
3
1.3k
Other Decks in Programming
See All in Programming
Pythonではじめるオープンデータ分析〜書籍の紹介と書籍で紹介しきれなかった事例の紹介〜
welliving
3
780
PostgreSQLで手軽にDuckDBを使う!DuckDB&pg_duckdb入門/osc25hi-duckdb
takahashiikki
0
240
re:Invent 2025 のイケてるサービスを紹介する
maroon1st
0
160
Grafana:建立系統全知視角的捷徑
blueswen
0
280
The Art of Re-Architecture - Droidcon India 2025
siddroid
0
160
副作用をどこに置くか問題:オブジェクト指向で整理する設計判断ツリー
koxya
1
330
TerraformとStrands AgentsでAmazon Bedrock AgentCoreのSSO認証付きエージェントを量産しよう!
neruneruo
4
2.4k
Canon EOS R50 V と R5 Mark II 購入でみえてきた最近のデジイチ VR180 事情、そして VR180 静止画に活路を見出すまで
karad
0
140
実はマルチモーダルだった。ブラウザの組み込みAI🧠でWebの未来を感じてみよう #jsfes #gemini
n0bisuke2
3
1.4k
ゲームの物理 剛体編
fadis
0
400
JETLS.jl ─ A New Language Server for Julia
abap34
2
470
AIエージェントの設計で注意するべきポイント6選
har1101
6
3k
Featured
See All Featured
Navigating Team Friction
lara
191
16k
エンジニアに許された特別な時間の終わり
watany
106
220k
Designing for humans not robots
tammielis
254
26k
We Have a Design System, Now What?
morganepeng
54
8k
For a Future-Friendly Web
brad_frost
180
10k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
From π to Pie charts
rasagy
0
100
The World Runs on Bad Software
bkeepers
PRO
72
12k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
[SF Ruby Conf 2025] Rails X
palkan
0
700
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.7k
Transcript
今年 会社でのレビ 今年 会社でのレビ ューで話した事 ューで話した事 銀座 Rails #16 Dec
13, 2019
⾃⼰紹介 ⾃⼰紹介
@ryosuke_sato
サトウリョウスケ サトウリョウスケ 株式会社フィードフォース ソーシャル PLUS バックエンドエンジニア 開発リーダー
今年の振り返り 今年の振り返り
銀座 RAILS に 3 回登壇しました 銀座 RAILS に 3 回登壇しました
銀座 Rails #07, Mar. 26 rubocop_challenger という gem を作った 銀座 Rails #10, June 21 My API Client 銀座 Rails #16, Dec. 13 今年 会社でのレビューで話した事 ← New!!!
RUBOCOP_CHALLENGER という GEM を RUBOCOP_CHALLENGER という GEM を 作った (#07)
作った (#07) https://github.com/ryz310/rubocop_challenger
MY API CLIENT (#10) MY API CLIENT (#10) class ExampleApiClient
< MyApiClient::Base endpoint 'https://example.com/v1' error_handling status_code: 200, json: { '$.errors.code': 10 }, raise: MyApiClient::ClientError attr_reader :access_token def initialize(access_token:) @access_token = access_token end # GET https://example.com/v1/users def get_users(condition:) https://github.com/ryz310/my_api_client
来年も登壇がんばりたい
今⽇話すこと 今⽇話すこと
今年 会社でのレビューで話した事 今年 会社でのレビューで話した事
クラスの設計がムズいという声を受けて 会社の勉強会では 45 分 x 2 回話した 今⽇はその中から⼀部を抜粋して持ってきまし た
1. 抽象度を揃える 2. 継承について考える 3. 現実から学ぶ
1. 抽象度を揃える 1. 抽象度を揃える
Q. これは何でしょう? トマトとモッツアレラチーズのサラダ 娼婦⾵スパゲティ ⼦⽺背⾁のリンゴソースかけ プリン
A. トニオさんのレストランのメニュー
例えばこの美味しそうなスパゲティを
仗助に材料別のところまでもどされると
いきなり違和感が出てきた トマトとモッツアレラチーズのサラダ スパゲティ茹でてニンニクと唐⾟⼦とプチトマ トを良い感じに炒めて絡める ← ⼦⽺背⾁のリンゴソースかけ プリン
▶ 抽象度を揃えよう 材料と調理⽅法について知っているのはトニオ さん(シェフ)だけで良いはず このクラスを扱う⼈はどのようなレベル感で対 象を知っているべきなのかを考えよう ※ 抽象化の⽅法はクラス化する、メソッド化す る、とかです。
抽象度が揃わないよくあるケース ワンライナーだからメソッド化しなかった の条件式だから ( 略 ) 単純な処理だから ( 略 )
処理が短くても抽象化すると ⾒えてくる事があります。
イタリアンの中に唐揚げ??? トマトとモッツアレラチーズのサラダ 娼婦⾵スパゲティ 若鶏の唐揚げ ← プリン
抽象化されてないとちょっと気付きづらいかも トマトとモッツアレラチーズをスライスして特 製ドレッシングをかける スパゲティ茹でてニンニクと唐⾟⼦とプチトマ トを良い感じに炒めて絡める チキンに下味をつけて油で揚げる プッチンする
抽象度を揃えるメリット クラスが単⼀責任の原則に従っているかどうか を確認しやすくなる 可読性が上がる リファクタリングしやすくなる
レビュー依頼に出す前に 抽象度が揃っているか確認しよう
抽象度の揃ってないコードで レビュー依頼に出してきたら …
None
2. 継承について考える 2. 継承について考える
クラスの継承にはいくつかの パターンがあると思います。
Interface Pattern Layer Pattern DSL Pattern and so on.
それっぽい名前つけましたが 僕が勝⼿に呼んでるだけです
結論から先に⾔うと
⾊んな継承パターン混ぜて使うのは やめた⽅が良いです
INTERFACE PATTERN INTERFACE PATTERN
クラスの使い⽅を規格化するための継承。 ⾝近な例だと Ruby webserver interface の 。 Rack
def call(env) [ 200, # (Integer) { 'Content-Type' => 'text/plain'
}, # (Hash) ['Hello World'] # (String ] end
Rack の規格(簡略版) メソッドを定義すること 引数 を受け取ること 戻り値は
楽器やってない⼈にはさっぱりかもですが、 エレキギターのエフェクターは 分かりやすい例だと思います
None
規格が揃っているから ⾊んなメーカーのエフェクターを 同じように組み合わせられる
LAYER PATTERN LAYER PATTERN
OSI 参照モデルと同じような考え⽅。 継承の階層ごとに扱う問題を分ける。
例えば JWT で認証するような API を作っている時。
ヘッダから JWT を検証する処理は で実装する。 class ApplicationController < ActionController::API before_action :verify_authentication_header
def verify_authentication_header decode_authentication_header rescue InvalidAuthenticationScheme render status: :bad_request rescue VerificationFailed, Expired render status: :unauthorized end end
継承先の⼦クラスでは JWT 認証の事は考えずに済む。 class SomeController < ApplicationController def index end
def show end end
DSL PATTERN DSL PATTERN
⾝近な例だと ActiveRecord とか。 class Company < ApplicationRecord has_many :employees validates
:name, presence: true scope :xxx end
親クラスを継承することで DSL ( ドメイン固有⾔語 ) が使えるようになる、 というパターン。
拙作の も DSL Pattern です(宣伝) class ExampleApiClient < MyApiClient::Base endpoint
'https://example.com/v1' error_handling status_code: 200, json: { '$.errors.code': 10 }, raise: MyApiClient::ClientError https://github.com/ryz310/my_api_client
3 つのパターンをご紹介しましたが、 親クラスに複数のパターンが 適⽤されている場合は 責務を負い過ぎている可能性があります。
特に DSL パターンはみんな (?) やりたがりますが、 プロダクトのコードではやらない⽅が 良いと思います。
どうしてもやりたい場合は gem にしましょう
3. 現実から学ぶ 3. 現実から学ぶ
世の中の事象は設計に役⽴つ事が多い 世の中の事象は設計に役⽴つ事が多い
⽔道は蛇⼝を右にひねれば⽔が⽌まる
右利きの⼈間の割合が世の中的に多い 右腕は右にひねる⽅が得意 ⽔を⽌める事 の⽅がやりやすい UI の⽅が安全
▶ 突き詰めて考えれば、 ⾃ずと仕様が決定される
時計は少しずつ早い時間にずれていく⏳
時計の誤差は少しずつ蓄積されていく 早まる⽅向に誤差を貯めた⽅が事故を防ぐこと に繋がりやすい (電波時計が無かった頃の話ね)
▶ どうやってもズレる事を防げないのであれば、 安全な⽅向に倒す
普段から⽇常を観察しておくと こういう知識が仕様決める時に役に⽴つ(かも)
他にも話したい事はたくさんありますが、 時間がないのでブログに書きます
ちなみにブログはまだ開設すらしてません (来年の⽬標です)
今年も⼀年お世話に 今年も⼀年お世話に なりました なりました
来年も宜しくお願い 来年も宜しくお願い 致します 致します END