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

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

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

Transcript

1. 「混ぜるな危険」 を推進する設計 2022/06/30 ミノ駆動
2. おしながき • 自己紹介 • 本日の理解目標 • 主語クソデカ問題 • 名前設計（命名）をクラス分割に活かす例 • 設計パターンの適用を隠れた概念発見に活かす例 • 発展編 より本質に迫る概念へ • まとめ
3. 自己紹介 ミノ駆動 @MinoDriven 仙塲 大也 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 悪しき構造が招く凄惨な結末を風刺した「クソコー ド動画」シリーズの作者。そして…
4. 買ってね！！
5. 本日の理解目標 命名や設計パターンは ただコードを綺麗にするためにあらず 異なる概念を仕分けする道具
6. 混ぜるな 危険
 私の 好きな 言葉です

7. 主語クソデカ問題
8. 様々なものと結合しやすい／巨大化しやすい
9. 状態によって振る舞いを切り替える分岐が爆増 ◦◦フラグが立っているときは配送中 △△と□□を満たすときは キャンペーン割引料金を計算 予約フラグが立っているときは 配送キャンセルメソッドで 例外をスロー
10. 「何かがおかしい」「責務がヘンなんじゃないか？」 と思って眺めていると…… 商品
11. 何か違うモノが混じってるのが見えてくる 商品 決済 売上分析 購入履歴 予約状況 請求金額
12. 単一責任原則や、何かしら設計の知識に触れたことの ある人はこう考えます。 責務の違うものが混じっているのでは？ 混ざらないようにクラスを分割すべきでは？
13. ところが ・トランザクションスクリプト ・仕様通りに動作するだけの実装 に慣れ親しんだ人にとっては……
14. （長大なトランザクションスクリプトに対して） これが当たり前でしょ？ 何を困っているんですか？ （混ざっているという指摘に対し） 混ざっている？神経質だな君は。
15. 混ざっている？ 
 私の 苦手な 言葉です
 神経質だな 君は 

16. コードは味も臭いもしない！ 何の観点も道具もないと 違いを認知できない！！ 文字通り存在そのものを認知できない。 だから「この人何言ってるんだ？」と言わんばかりにポカン とされるし、外星人宇宙人扱いされる。
17. 違いを見分けるための 観点や道具が必要
18. そのための 　・名前設計（命名） 　・設計パターン
19. 名前設計（命名）を クラス分割に活かす例
20. 商品 注文 巨大な商品クラスの中に注文に 関するロジックが埋没している
21. 注文品 商品 「注文品クラス」として切り 出し、商品注文に関する ロジックをカプセル化す る。
23. 設計パターンの適用を 隠れた概念発見に活かす例
24. 複雑なロジックの中でリストへの追加処理をしている箇所があったので、 ひとまずFirst Class Collectionパターンで当該箇所を切り出してみた。
25. 注文時の商品追加といえば「買い物かご」！ Products -> ShoppingCartに名前改善することで、 コードの意図理解が進む。 買い物かごに関する知識を凝集し、それ以外を疎にしやすくなる。
26. 設計パターンで切り出すことで 知識の交通整理や 隠れた概念発見の契機になる
27. そういえば商品クラス、クソデカで複雑だな……ん！？ 買い物かごに追加するものは、商品ではなく注文品では！？ 商品クラスから注文関連の知識だけを集約した注文品クラスを抽出して みるか？ 知識の深まりが、さらに構造改善へつながることも
28. 発展編　より本質に迫る概念へ
29. 「混ぜるな危険」を解消し さらに純度の高い概念を蒸留していく より本質を解決する 「深いモデル」が見つかる
30. アクチュアル（現働的） ヴァーチャル（潜在的） 「自転車に乗る人」と「自転車」の、 物理的存在に囚われがち。 存在の脱構築 人 vs 自転車といった区別なく、全てのもの が複雑に関係し合う次元として解釈。モデリ ングで役に立つ考え方。 『現代思想入門』著：千葉雅也、 2022年刊行、講談社
31. 物理的存在としてモ デリング 利用者 User 利用者：モデルが１：１では 巨大化複雑化し、 使いにくいモデルになりがち
32. 存在の脱構築 利用者 購入側 アカウント 個人 プロフィール 認証 認可 出品側 アカウント 会員特典設定 物理的存在から離れ、役に立つ目的単位で モデリングすると、１：Nの関係性になる（こと がとても多い）。
33. エヴァンス本　シェアパイの例 ブレイクスルー シェアパイ ローン出資 ローン調整 「シェアパイ」という概念を見出したことで、ローンの金額計算誤差 や特殊ケースに対応するための複雑なロジックが消え去った。顧客 にもわかりやすい概念として定着した。
34. 「売買契約」という法的概念とすることで支払条件（支払期日など） の存在を認知できる。法的な有効性を発揮できるモデルとなる。 商品購入？？ 法的な意味付け 商品購入 ID 購入日時 受取希望日 売買契約 ID 契約締結日時 引渡希望日 支払期日 決済方法
35. RPGツクールの例 魔王ならこの前急性ア ルコール中毒で死ん だぞい。 村人 宝箱 内部ではどういうオブジェクトとして 表現されているだろうか？
36. RPGツクールの例 魔王ならこの前急性ア ルコール中毒で死ん だぞい。 村人 宝箱 双方とも Game_Event として表現されている。 見た目が違うだけでメッセージ表示やアイテム入手など、 ゲーム中のイベントを発生させるオブジェクト。
37. こうした機能性に大きく貢献する 「深いモデル」を見出す上では、 混ざって混乱したロジックがあるような状態では困難。 リファクタリングを繰り返し、 概念の純度を高めていった先に 初めて見出せる。
38. まとめ 命名や設計パターンは異なる概念を仕分けする道具。 「混ざり」を解消し、さらに純度の高い概念を蒸留していく と、機能性に大きく貢献する「深いモデル」発見の契機にな る。