Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
「混ぜるな危険」 を推進する設計 2022/06/30 ミノ駆動
Slide 2
Slide 2 text
おしながき ● 自己紹介 ● 本日の理解目標 ● 主語クソデカ問題 ● 名前設計（命名）をクラス分割に活かす例 ● 設計パターンの適用を隠れた概念発見に活かす例 ● 発展編 より本質に迫る概念へ ● まとめ
Slide 3
Slide 3 text
自己紹介 ミノ駆動 @MinoDriven 仙塲 大也 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 悪しき構造が招く凄惨な結末を風刺した「クソコー ド動画」シリーズの作者。そして…
Slide 4
Slide 4 text
買ってね！！
Slide 5
Slide 5 text
本日の理解目標 命名や設計パターンは ただコードを綺麗にするためにあらず 異なる概念を仕分けする道具
Slide 6
Slide 6 text
混ぜるな 危険 私の 好きな 言葉です
Slide 7
Slide 7 text
主語クソデカ問題
Slide 8
Slide 8 text
様々なものと結合しやすい／巨大化しやすい
Slide 9
Slide 9 text
状態によって振る舞いを切り替える分岐が爆増 ○○フラグが立っているときは配送中 △△と□□を満たすときは キャンペーン割引料金を計算 予約フラグが立っているときは 配送キャンセルメソッドで 例外をスロー
Slide 10
Slide 10 text
「何かがおかしい」「責務がヘンなんじゃないか？」 と思って眺めていると…… 商品
Slide 11
Slide 11 text
何か違うモノが混じってるのが見えてくる 商品 決済 売上分析 購入履歴 予約状況 請求金額
Slide 12
Slide 12 text
単一責任原則や、何かしら設計の知識に触れたことの ある人はこう考えます。 責務の違うものが混じっているのでは？ 混ざらないようにクラスを分割すべきでは？
Slide 13
Slide 13 text
ところが ・トランザクションスクリプト ・仕様通りに動作するだけの実装 に慣れ親しんだ人にとっては……
Slide 14
Slide 14 text
（長大なトランザクションスクリプトに対して） これが当たり前でしょ？ 何を困っているんですか？ （混ざっているという指摘に対し） 混ざっている？神経質だな君は。
Slide 15
Slide 15 text
混ざっている？ 私の 苦手な 言葉です 神経質だな 君は
Slide 16
Slide 16 text
コードは味も臭いもしない！ 何の観点も道具もないと 違いを認知できない！！ 文字通り存在そのものを認知できない。 だから「この人何言ってるんだ？」と言わんばかりにポカン とされるし、外星人宇宙人扱いされる。
Slide 17
Slide 17 text
違いを見分けるための 観点や道具が必要
Slide 18
Slide 18 text
そのための ・名前設計（命名） ・設計パターン
Slide 19
Slide 19 text
名前設計（命名）を クラス分割に活かす例
Slide 20
Slide 20 text
商品 注文 巨大な商品クラスの中に注文に 関するロジックが埋没している
Slide 21
Slide 21 text
注文品 商品 「注文品クラス」として切り 出し、商品注文に関する ロジックをカプセル化す る。
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
設計パターンの適用を 隠れた概念発見に活かす例
Slide 24
Slide 24 text
複雑なロジックの中でリストへの追加処理をしている箇所があったので、 ひとまずFirst Class Collectionパターンで当該箇所を切り出してみた。
Slide 25
Slide 25 text
注文時の商品追加といえば「買い物かご」！ Products -> ShoppingCartに名前改善することで、 コードの意図理解が進む。 買い物かごに関する知識を凝集し、それ以外を疎にしやすくなる。
Slide 26
Slide 26 text
設計パターンで切り出すことで 知識の交通整理や 隠れた概念発見の契機になる
Slide 27
Slide 27 text
そういえば商品クラス、クソデカで複雑だな……ん！？ 買い物かごに追加するものは、商品ではなく注文品では！？ 商品クラスから注文関連の知識だけを集約した注文品クラスを抽出して みるか？ 知識の深まりが、さらに構造改善へつながることも
Slide 28
Slide 28 text
発展編 より本質に迫る概念へ
Slide 29
Slide 29 text
「混ぜるな危険」を解消し さらに純度の高い概念を蒸留していく より本質を解決する 「深いモデル」が見つかる
Slide 30
Slide 30 text
アクチュアル（現働的） ヴァーチャル（潜在的） 「自転車に乗る人」と「自転車」の、 物理的存在に囚われがち。 存在の脱構築 人 vs 自転車といった区別なく、全てのもの が複雑に関係し合う次元として解釈。モデリ ングで役に立つ考え方。 『現代思想入門』著：千葉雅也、 2022年刊行、講談社
Slide 31
Slide 31 text
物理的存在としてモ デリング 利用者 User 利用者：モデルが１：１では 巨大化複雑化し、 使いにくいモデルになりがち
Slide 32
Slide 32 text
存在の脱構築 利用者 購入側 アカウント 個人 プロフィール 認証 認可 出品側 アカウント 会員特典設定 物理的存在から離れ、役に立つ目的単位で モデリングすると、１：Nの関係性になる（こと がとても多い）。
Slide 33
Slide 33 text
エヴァンス本 シェアパイの例 ブレイクスルー シェアパイ ローン出資 ローン調整 「シェアパイ」という概念を見出したことで、ローンの金額計算誤差 や特殊ケースに対応するための複雑なロジックが消え去った。顧客 にもわかりやすい概念として定着した。
Slide 34
Slide 34 text
「売買契約」という法的概念とすることで支払条件（支払期日など） の存在を認知できる。法的な有効性を発揮できるモデルとなる。 商品購入？？ 法的な意味付け 商品購入 ID 購入日時 受取希望日 売買契約 ID 契約締結日時 引渡希望日 支払期日 決済方法
Slide 35
Slide 35 text
RPGツクールの例 魔王ならこの前急性ア ルコール中毒で死ん だぞい。 村人 宝箱 内部ではどういうオブジェクトとして 表現されているだろうか？
Slide 36
Slide 36 text
RPGツクールの例 魔王ならこの前急性ア ルコール中毒で死ん だぞい。 村人 宝箱 双方とも Game_Event として表現されている。 見た目が違うだけでメッセージ表示やアイテム入手など、 ゲーム中のイベントを発生させるオブジェクト。
Slide 37
Slide 37 text
こうした機能性に大きく貢献する 「深いモデル」を見出す上では、 混ざって混乱したロジックがあるような状態では困難。 リファクタリングを繰り返し、 概念の純度を高めていった先に 初めて見出せる。
Slide 38
Slide 38 text
まとめ 命名や設計パターンは異なる概念を仕分けする道具。 「混ざり」を解消し、さらに純度の高い概念を蒸留していく と、機能性に大きく貢献する「深いモデル」発見の契機にな る。