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.8k
今年 会社でのレビューで話した事
レビューでクラスの設計がムズいという声を受けて幾つか社内で解説をしたのですが、今日はその中から一部を抜粋して持ってきました。
Ryz310
December 13, 2019
Tweet
Share
More Decks by Ryz310
See All by Ryz310
Redis::Objects で遊んでみよう
ryz310
0
760
My API Client
ryz310
0
150
MyApiClient
ryz310
3
1.2k
Other Decks in Programming
See All in Programming
ヤプリ新卒SREの オンボーディング
masaki12
0
130
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
初めてDefinitelyTypedにPRを出した話
syumai
0
410
型付き API リクエストを実現するいくつかの手法とその選択 / Typed API Request
euxn23
8
2.2k
CSC509 Lecture 11
javiergs
PRO
0
180
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
受け取る人から提供する人になるということ
little_rubyist
0
230
Tauriでネイティブアプリを作りたい
tsucchinoko
0
370
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
1
290
Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow
cer
PRO
0
330
Better Code Design in PHP
afilina
PRO
0
130
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
350
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
It's Worth the Effort
3n
183
27k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
Six Lessons from altMBA
skipperchong
27
3.5k
Optimizing for Happiness
mojombo
376
70k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Building an army of robots
kneath
302
43k
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