Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「混ぜるな危険」を推進する設計

 「混ぜるな危険」を推進する設計

2022/06/30開催の、こちらのオンラインイベントで用いた登壇資料です。

BPStudy#178〜成長し続け、変更を楽に安全にできるソフトウェア設計とは
https://bpstudy.connpass.com/event/250694/

MinoDriven

July 01, 2022
Tweet

More Decks by MinoDriven

Other Decks in Programming

Transcript

  1. 「混ぜるな危険」
    を推進する設計
    2022/06/30
    ミノ駆動

    View full-size slide

  2. おしながき
    ● 自己紹介
    ● 本日の理解目標
    ● 主語クソデカ問題
    ● 名前設計(命名)をクラス分割に活かす例
    ● 設計パターンの適用を隠れた概念発見に活かす例
    ● 発展編 より本質に迫る概念へ
    ● まとめ

    View full-size slide

  3. 自己紹介
    ミノ駆動
    @MinoDriven
    仙塲 大也
    電子機器メーカーや大手精密機器メーカー、そし
    てクラウドワークスを経て、2021年4月に
    READYFOR株式会社にジョイン。
    アプリケーションアーキテクトとして、レガシーシス
    テムのリファクタリングや拡張性向上設計など、シ
    ステム設計に従事。
    悪しき構造が招く凄惨な結末を風刺した「クソコー
    ド動画」シリーズの作者。そして…

    View full-size slide

  4. 買ってね!!

    View full-size slide

  5. 本日の理解目標
    命名や設計パターンは
    ただコードを綺麗にするためにあらず
    異なる概念を仕分けする道具

    View full-size slide

  6. 混ぜるな
    危険

    私の
    好きな
    言葉です


    View full-size slide

  7. 主語クソデカ問題

    View full-size slide

  8. 様々なものと結合しやすい/巨大化しやすい

    View full-size slide

  9. 状態によって振る舞いを切り替える分岐が爆増
    ○○フラグが立っているときは配送中
    △△と□□を満たすときは
    キャンペーン割引料金を計算
    予約フラグが立っているときは
    配送キャンセルメソッドで
    例外をスロー

    View full-size slide

  10. 「何かがおかしい」「責務がヘンなんじゃないか?」
    と思って眺めていると……
    商品

    View full-size slide

  11. 何か違うモノが混じってるのが見えてくる
    商品
    決済
    売上分析
    購入履歴 予約状況
    請求金額

    View full-size slide

  12. 単一責任原則や、何かしら設計の知識に触れたことの
    ある人はこう考えます。
    責務の違うものが混じっているのでは?
    混ざらないようにクラスを分割すべきでは?

    View full-size slide

  13. ところが
    ・トランザクションスクリプト
    ・仕様通りに動作するだけの実装
    に慣れ親しんだ人にとっては……

    View full-size slide

  14. (長大なトランザクションスクリプトに対して)
    これが当たり前でしょ?
    何を困っているんですか?
    (混ざっているという指摘に対し)
    混ざっている?神経質だな君は。

    View full-size slide

  15. 混ざっている?

    私の
    苦手な
    言葉です

    神経質だな
    君は

    View full-size slide

  16. コードは味も臭いもしない!
    何の観点も道具もないと
    違いを認知できない!!
    文字通り存在そのものを認知できない。
    だから「この人何言ってるんだ?」と言わんばかりにポカン
    とされるし、外星人宇宙人扱いされる。

    View full-size slide

  17. 違いを見分けるための
    観点や道具が必要

    View full-size slide

  18. そのための
     ・名前設計(命名)
     ・設計パターン

    View full-size slide

  19. 名前設計(命名)を
    クラス分割に活かす例

    View full-size slide

  20. 商品
    注文
    巨大な商品クラスの中に注文に
    関するロジックが埋没している

    View full-size slide

  21. 注文品
    商品
    「注文品クラス」として切り
    出し、商品注文に関する
    ロジックをカプセル化す
    る。

    View full-size slide

  22. 設計パターンの適用を
    隠れた概念発見に活かす例

    View full-size slide

  23. 複雑なロジックの中でリストへの追加処理をしている箇所があったので、
    ひとまずFirst Class Collectionパターンで当該箇所を切り出してみた。

    View full-size slide

  24. 注文時の商品追加といえば「買い物かご」!
    Products -> ShoppingCartに名前改善することで、
    コードの意図理解が進む。
    買い物かごに関する知識を凝集し、それ以外を疎にしやすくなる。

    View full-size slide

  25. 設計パターンで切り出すことで
    知識の交通整理や
    隠れた概念発見の契機になる

    View full-size slide

  26. そういえば商品クラス、クソデカで複雑だな……ん!?
    買い物かごに追加するものは、商品ではなく注文品では!?
    商品クラスから注文関連の知識だけを集約した注文品クラスを抽出して
    みるか?
    知識の深まりが、さらに構造改善へつながることも

    View full-size slide

  27. 発展編 より本質に迫る概念へ

    View full-size slide

  28. 「混ぜるな危険」を解消し
    さらに純度の高い概念を蒸留していく
    より本質を解決する
    「深いモデル」が見つかる

    View full-size slide

  29. アクチュアル(現働的) ヴァーチャル(潜在的)
    「自転車に乗る人」と「自転車」の、
    物理的存在に囚われがち。
    存在の脱構築
    人 vs 自転車といった区別なく、全てのもの
    が複雑に関係し合う次元として解釈。モデリ
    ングで役に立つ考え方。
    『現代思想入門』著:千葉雅也、 2022年刊行、講談社

    View full-size slide

  30. 物理的存在としてモ
    デリング
    利用者
    User
    利用者:モデルが1:1では
    巨大化複雑化し、
    使いにくいモデルになりがち

    View full-size slide

  31. 存在の脱構築
    利用者
    購入側
    アカウント
    個人
    プロフィール
    認証
    認可
    出品側
    アカウント
    会員特典設定
    物理的存在から離れ、役に立つ目的単位で
    モデリングすると、1:Nの関係性になる(こと
    がとても多い)。

    View full-size slide

  32. エヴァンス本 シェアパイの例
    ブレイクスルー シェアパイ
    ローン出資
    ローン調整
    「シェアパイ」という概念を見出したことで、ローンの金額計算誤差
    や特殊ケースに対応するための複雑なロジックが消え去った。顧客
    にもわかりやすい概念として定着した。

    View full-size slide

  33. 「売買契約」という法的概念とすることで支払条件(支払期日など)
    の存在を認知できる。法的な有効性を発揮できるモデルとなる。
    商品購入??
    法的な意味付け
    商品購入
    ID
    購入日時
    受取希望日
    売買契約
    ID
    契約締結日時
    引渡希望日
    支払期日
    決済方法

    View full-size slide

  34. RPGツクールの例
    魔王ならこの前急性ア
    ルコール中毒で死ん
    だぞい。
    村人 宝箱
    内部ではどういうオブジェクトとして
    表現されているだろうか?

    View full-size slide

  35. RPGツクールの例
    魔王ならこの前急性ア
    ルコール中毒で死ん
    だぞい。
    村人 宝箱
    双方とも Game_Event として表現されている。
    見た目が違うだけでメッセージ表示やアイテム入手など、
    ゲーム中のイベントを発生させるオブジェクト。

    View full-size slide

  36. こうした機能性に大きく貢献する
    「深いモデル」を見出す上では、
    混ざって混乱したロジックがあるような状態では困難。
    リファクタリングを繰り返し、
    概念の純度を高めていった先に
    初めて見出せる。

    View full-size slide

  37. まとめ
    命名や設計パターンは異なる概念を仕分けする道具。
    「混ざり」を解消し、さらに純度の高い概念を蒸留していく
    と、機能性に大きく貢献する「深いモデル」発見の契機にな
    る。

    View full-size slide