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
Facade Patternで磨く、コードの可読性と分解力 / MIERUNE BBQ #13
Search
MIERUNE
PRO
November 20, 2024
Technology
0
440
Facade Patternで磨く、コードの可読性と分解力 / MIERUNE BBQ #13
MIERUNE BBQ #13 -
https://mierune.connpass.com/event/335812/
Shinsuke Nakamori
MIERUNE
PRO
November 20, 2024
Tweet
Share
More Decks by MIERUNE
See All by MIERUNE
連続的な到達圏を表示する QGISプラグインを作ってみた
mierune
PRO
0
610
ハザードマップゲームの作り方〜ハザード情報をゲームのパラメーターに落とし込む〜 / FOSS4G 2024 Japan
mierune
PRO
0
680
MIERUNEとQGIS、そしてQGIS事業のご紹介 / FOSS4G 2024 Japan
mierune
PRO
0
630
QGISで実現するもっと分かりやすい森林ゾーニング / FOSS4G 2024 Japan
mierune
PRO
0
700
君はこの色の違いを見ることができるか / MIERUNE BBQ #12
mierune
PRO
0
540
クーダでハニワ / MIERUNE BBQ #12
mierune
PRO
0
490
位置情報とオープンソースがやりたくてMIERUNEに転職した話 〜経歴、事例紹介、GISへのいざない〜 / MIERUNE JCT - Tokyo 2024
mierune
PRO
0
1.6k
クロージング / MIERUNE JCT - Tokyo 2024
mierune
PRO
0
1.2k
オープニング / MIERUNE JCT - Tokyo 2024
mierune
PRO
1
1.3k
Other Decks in Technology
See All in Technology
自動テストのコストと向き合ってみた
qa
0
110
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
310
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
970
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
420
KMP の Swift export
kokihirokawa
0
330
Green Tea Garbage Collector の今
zchee
PRO
2
390
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
170
いまさら聞けない ABテスト入門
skmr2348
1
200
生成AI_その前_に_マルチクラウド時代の信頼できるデータを支えるSnowflakeメタデータ活用術.pdf
cm_mikami
0
110
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
130
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.9k
リーダーになったら未来を語れるようになろう/Speak the Future
sanogemaru
0
280
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Embracing the Ebb and Flow
colly
88
4.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Gamification - CAS2011
davidbonilla
81
5.5k
Being A Developer After 40
akosma
91
590k
We Have a Design System, Now What?
morganepeng
53
7.8k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Transcript
位置情報の新しいイノベーションへ Facade Patternで磨く、 コードの可読性と分解力 中森 紳介
©Project PLATEAU / MLIT Japan 中森 紳介 自己紹介 NAKAMORI Shinsuke
2024年2月 MIERUNE入社 神奈川在住で普段はフルリモート勤務 普段のお仕事:QGISプラグイン開発など BBQ参加歴:#10のみ(今日が2回目) (代打系)GISエンジニア
© 地理院地図 全国最新写真(シームレス) 普段からコードを書いている人🙋
© 地理院地図 全国最新写真(シームレス) 普段からコードの可読性を 意識している人🙋
© 地理院地図 全国最新写真(シームレス) 「コードの可読性」って なんですか?
©Project PLATEAU / MLIT Japan 諸説あるかもしれませんが コードの可読性とは コードの可読性 = どれだけ読みやすいか
©Project PLATEAU / MLIT Japan 諸説あるかもしれませんが コードの可読性とは コードの可読性 = どれだけ読みやすいか
コードの可読性 = どれだけ処理内容を追いやすいか
©Project PLATEAU / MLIT Japan フードデリバリーで商品を届ける一連のフローについて考える フードデリバリーの例で考えてみる
©Project PLATEAU / MLIT Japan class Delivery: def 商品を届ける(self, 注文先:
レストラン, 商品リスト: list, 目的地: str): お店の住所 = 注文先.お店の場所を確認する() 配達員リスト = [配達員A, 配達員B, 配達員C] 最短時間 = float("inf") for 対象者 in 配達員リスト: 現在地 = 対象者.現在地() 所要時間 = お店までの到達時間(現在地, お店の住所) if 所要時間 < 最短時間: 配達する人 = 対象者 最短時間 = 所要時間 所要時間 = 注文先.所要時間を確認する(商品リスト) レジ袋 = 注文先.商品を作る(商品リスト) 経路 = 配達する人.配達経路を確認する(目的地) 完了報告 = 配達する人.商品を運ぶ(レジ袋, 経路) if 完了報告: print("商品をお届けしました") return True else: print("商品の配達に失敗しました") return False
©Project PLATEAU / MLIT Japan class Delivery: def 商品を届ける(self, 注文先:
レストラン, 商品リスト: list, 目的地: str): お店の住所 = 注文先.お店の場所を確認する() 配達員リスト = [配達員A, 配達員B, 配達員C] 最短時間 = float("inf") for 対象者 in 配達員リスト: 現在地 = 対象者.現在地() 所要時間 = お店までの到達時間(現在地, お店の住所) if 所要時間 < 最短時間: 配達する人 = 対象者 最短時間 = 所要時間 所要時間 = 注文先.所要時間を確認する(商品リスト) レジ袋 = 注文先.商品を作る(商品リスト) 経路 = 配達する人.配達経路を確認する(目的地) 完了報告 = 配達する人.商品を運ぶ(レジ袋, 経路) if 完了報告: print("商品をお届けしました") return True else: print("商品の配達に失敗しました") return False 具体的な処理内容と 関数化された処理が混在していて 処理全体のフローが ぱっと見で把握しにくい
©Project PLATEAU / MLIT Japan class DeliveryFacadePattern: def 商品を届ける(self, 注文先:
レストラン, 商品リスト: list, 目的地: str): アプリ = Application() お店の住所 = 注文先.お店の場所を確認する() 配達する人: 配達員 = アプリ.近くの配達員を検索する(お店の住所) 所要時間 = 注文先.所要時間を確認する(商品リスト) アプリ.所要時間を表示する(所要時間) レジ袋 = 注文先.商品を作る(商品リスト) 経路 = 配達する人.配達経路を確認する(目的地) 完了報告 = 配達する人.商品を運ぶ(レジ袋, 経路) アプリ.利用者に報告する(完了報告)
©Project PLATEAU / MLIT Japan class DeliveryFacadePattern: def 商品を届ける(self, 注文先:
レストラン, 商品リスト: list, 目的地: str): アプリ = Application() お店の住所 = 注文先.お店の場所を確認する() 配達する人: 配達員 = アプリ.近くの配達員を検索する(お店の住所) 所要時間 = 注文先.所要時間を確認する(商品リスト) アプリ.所要時間を表示する(所要時間) レジ袋 = 注文先.商品を作る(商品リスト) 経路 = 配達する人.配達経路を確認する(目的地) 完了報告 = 配達する人.商品を運ぶ(レジ袋, 経路) アプリ.利用者に報告する(完了報告) 具体的な処理内容は 1行も書いてないが、 処理全体のフローが理解できる
©Project PLATEAU / MLIT Japan コンピュータソフトウェアのデザインパターンの一つ Facade Pattern 参照:https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 Facadeクラス
• 複雑な実装を持たない • 基本、処理を投げるだけ 複数のサブシステム • 具体的な実装を持つ
©Project PLATEAU / MLIT Japan コンピュータソフトウェアのデザインパターンの一つ Facade Pattern 参照:https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 Facadeクラス
• 複雑な実装を持たない • 基本、処理を投げるだけ 複数のサブシステム • 具体的な実装を持つ どう分けるのが 適切なの?
©Project PLATEAU / MLIT Japan 単一責任の原則が一般的(なはず 単一責任の原則について調べると以下のような記述を見かける •クラスは変更理由が一つだけであるべき •クラスの目的は一つだけで、それが変わった場合のみ変更される •1つのクラスは1つだけの責任を持たなければならない
©Project PLATEAU / MLIT Japan いやいや、その「単一」が分からんのじゃ 「配達員」は単一なの?それとも「配達する」が単一なの? 配達員のクラスで まとめていいの? 「配達する」って
クラスを作るの? 細かすぎない? まあシステムの 大きさとかに寄るよね そこはセンスの 問題かな
©Project PLATEAU / MLIT Japan 「単一」の迷路に迷い込んでしまったら 私はセンスがないので、以下の手順をよく踏みます 1)とにかく思いついた「単一」っぽいものをバラバラに列挙する 2)同程度の粒度のものをグルーピングする 3)構造化して並べ直す
4)抜け漏れがないか、チェックする 5)具体的な処理を必要とする一つ上の粒度を「単一」と考えてみる 6)しっくりこなければ、粒度を一段変更してみる
© 地理院地図 全国最新写真(シームレス) 試しにやってみる
©Project PLATEAU / MLIT Japan 思いついたやつをバラバラに列挙する 商品代を算出する お代を受け取る 近くの配達員を探す 商品を袋に詰める
調理する 調理時間を確認する お店の場所を確認する 現在地を取得する 配達する 利用者に報告する 所要時間を表示する レストラン 配達員
©Project PLATEAU / MLIT Japan 同程度のものをグルーピング レストラン 配達員 お店の場所を確認する 調理時間を確認する
調理する 近くの配達員を探す 所要時間を表示する 利用者に報告する 商品を袋に詰める 現在地を取得する 配達経路を確認する 配達する 商品を渡す お代を受け取る 商品代を算出する 粒度:大 粒度:小
©Project PLATEAU / MLIT Japan 構造化して並べ直す システム レストラン 配達員 お店の場所を確認する
調理時間を確認する 調理する 商品を袋に詰める 商品代を算出する 現在地を取得する 配達経路を確認する 配達する 商品を渡す お代を受け取る 近くの配達員を探す 所要時間を表示する 利用者に報告する
©Project PLATEAU / MLIT Japan 抜け漏れがないか確認する システム レストラン 配達員 お店の場所を確認する
調理時間を確認する 調理する 商品を袋に詰める 商品代を算出する 現在地を取得する 配達経路を確認する 配達する 商品を渡す お代を受け取る 近くの配達員を探す 所要時間を表示する 利用者に報告する システムから伸びる 対象の粒度が あってないな 処理内容を グルーピング できないかな?
©Project PLATEAU / MLIT Japan 抜け漏れがないか確認する システム レストラン 配達員 アプリケーション
データ登録 実務 お店の場所を確認する 商品代を算出する 調理時間を確認する 調理する 商品を袋に詰める 待機状態 配達 会計処理 表示 処理 現在地を取得する 配達経路を確認する 配達する 商品を渡す お代を受け取る 所要時間を表示する 利用者に報告する 近くの配達員を探す
©Project PLATEAU / MLIT Japan 具体的な処理を書く一段上を単一とする システム レストラン 配達員 アプリケーション
データ登録 実務 お店の場所を確認する 商品代を算出する 調理時間を確認する 調理する 商品を袋に詰める 待機状態 配達 会計処理 表示 処理 現在地を取得する 配達経路を確認する 配達する 商品を渡す お代を受け取る 所要時間を表示する 利用者に報告する 近くの配達員を探す
©Project PLATEAU / MLIT Japan Facade Patternで呼び出すクラスの粒度を検討するには、システム全 体を適切に分解して、構造化する能力が必要(だと思っている これが「分解力」である(決めつけ
©Project PLATEAU / MLIT Japan 「分解力」が発揮できる場面の例 •フォルダ整理 •資料作成 •要因分析 などなど
実はコーディング以外でも使えます
©Project PLATEAU / MLIT Japan 物事の「分解力」を磨いて、業務全体の可読性を上げていこう ということで クラス設計の粒度が揃う データを探しやすくなる 読みやすい構成に
©Project PLATEAU / MLIT Japan (余談)なお、個人的には 今回の例なら、配達員やレストランのFacadeクラスを用意する方が好き システムFacade アプリFacade 配達員Facade
レストランFacade 配達モジュール 会計モジュール
©Project PLATEAU / MLIT Japan 洗い出した項目を構造化するのが、とても楽になる オススメしたいもの①:XMind 一旦、端に置いておくこともできる ドラッグ&ドロップで 簡単に構造を組み替えることができる
©Project PLATEAU / MLIT Japan 「分解力」高めるなら、キーボードも適切な粒度に分解せねば オススメしたいもの②:分割キーボード キーボード 右手用キーボード 左手用キーボード
Q W E Y U I … … ↑先週手に入れたやつ
© 地理院地図 全国最新写真(シームレス) •Facade Patternでフローを見やすくしよう •呼び出すサブシステムは、適切な粒度にしよう •求められる能力は、物事の分解と構造化 •「分割キーボードはいいぞ」 まとめ