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
420
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
580
ハザードマップゲームの作り方〜ハザード情報をゲームのパラメーターに落とし込む〜 / FOSS4G 2024 Japan
mierune
PRO
0
650
MIERUNEとQGIS、そしてQGIS事業のご紹介 / FOSS4G 2024 Japan
mierune
PRO
0
610
QGISで実現するもっと分かりやすい森林ゾーニング / FOSS4G 2024 Japan
mierune
PRO
0
660
君はこの色の違いを見ることができるか / MIERUNE BBQ #12
mierune
PRO
0
520
クーダでハニワ / MIERUNE BBQ #12
mierune
PRO
0
470
位置情報とオープンソースがやりたくてMIERUNEに転職した話 〜経歴、事例紹介、GISへのいざない〜 / MIERUNE JCT - Tokyo 2024
mierune
PRO
0
1.5k
クロージング / MIERUNE JCT - Tokyo 2024
mierune
PRO
0
1.1k
オープニング / MIERUNE JCT - Tokyo 2024
mierune
PRO
1
1.3k
Other Decks in Technology
See All in Technology
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
480
テストを軸にした生き残り術
kworkdev
PRO
0
210
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1.1k
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
100
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
3
340
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
Django's GeneratedField by example - DjangoCon US 2025
pauloxnet
0
160
MagicPod導入から半年、オープンロジQAチームで実際にやったこと
tjoko
0
110
IoT x エッジAI - リアルタイ ムAI活用のPoCを今すぐ始め る方法 -
niizawat
0
120
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
1
230
EncryptedSharedPreferences が deprecated になっちゃった!どうしよう! / Oh no! EncryptedSharedPreferences has been deprecated! What should I do?
yanzm
0
490
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
130
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Six Lessons from altMBA
skipperchong
28
4k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
580
The Power of CSS Pseudo Elements
geoffreycrofte
77
6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Code Reviewing Like a Champion
maltzj
525
40k
Become a Pro
speakerdeck
PRO
29
5.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
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でフローを見やすくしよう •呼び出すサブシステムは、適切な粒度にしよう •求められる能力は、物事の分解と構造化 •「分割キーボードはいいぞ」 まとめ