『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code

Slide 1

Slide 1 text

『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 2022/11/22 ミノ駆動

Slide 2

Slide 2 text

こんばんは、ミノ駆動です

Slide 3

Slide 3 text

まずはみなさん

Slide 4

Slide 4 text

ハッシュタグ #Forkwell_Library 付きで「設計なんもわからん」とツイートしましょう

Slide 5

Slide 5 text

ここで働いています

Slide 6

Slide 6 text

最近ニュースになったクラウドファンディング

Slide 7

Slide 7 text

自己紹介大手電機メーカーなどを経て、 2021年4月にREADYFOR㈱にジョイン。アプリケーションアーキテクトとして、レガシーシステムのリファクタリングや拡張性向上設計など、システム設計に従事。ミノ駆動 @MinoDriven

Slide 8

Slide 8 text

著作紹介『良いコード／悪いコードで学ぶ設計入門』技術的負債を作り込まない、変更容易性の高い設計を学ぶ、初級〜中級向け入門書。新卒エンジニアに最適です。輪読会も多数開催されております。発売5ヶ月で7刷重版発行部数2万部超え達成

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

「コード」と書いてるけどクラス設計中心的に扱っているのはクラス設計安全に変更にできるようになるためのクラス構造を解説構造とはインスタンス変数、メソッドのシグニチャ、分岐構造 etc.. 構造を説明しようとするとロジック細部に至るため「コード」と銘打っている

Slide 15

Slide 15 text

本書の論理展開変更容易性の低いコードを提示何が問題か、なぜ問題となるかを解説変更容易性の高いコード（設計）を提示なぜ問題解決されるのかを解説

Slide 16

Slide 16 text

多くのアンチパターンを網羅再代入生焼けオブジェクト staticメソッドの誤用プリミティブ型執着 Common, Util フラグ引数 switchクローン多重責務モノベース命名多重ネストスマートUI 貧血ドメインモデル退化コメントダブルミーニング例外の握りつぶしトランザクションスクリプトパターン ※ここで挙げたのはごく一部にすぎない

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

深める① 理由を説明できる力が身につく

Slide 23

Slide 23 text

Slide 24

Slide 24 text

利点１：再現性が高まる再現性：同じ方法、同じ条件が揃ったときに、同じ事象を再現できる度合い対処の仕方、有効である理由を知っていれば、悪しきコードに遭遇した際、同じ方法ですぐに対応できるようになる。

Slide 25

Slide 25 text

利点２：応用が効くようになる基礎がなっていないものを応用しようとすると、守られるべき基礎がすっぽ抜けて台無しになる。本書では理由を重厚に説明しているので、基礎固めになる。そのため自分で応用、発展させていくことができる。

Slide 26

Slide 26 text

利点３：技術選択の精度が高まる設計にはコストがかかる開発費も時間も有限設計には無限にコストをかけられない設計の仕組みや理屈を理解していれば例えば実装上の問題が軽微であれば設計コストをかけない変更頻度が高く変更リスクが大きい箇所は設計コストをかけるといった感じで設計的に妥当な判断ができるようになる銀の弾丸に陥らずに済む

Slide 27

Slide 27 text

利点４：チームや上司に設計理由を説明できるようになる設計リテラシーが高くないチームに新しい設計を導入する際、理由や効果を示して説得しなければならない拙著は理由を手厚く解説しているため、なぜその設計をしなければならないのか、理由の知識を深める手助けになる筆者が実際に理論武装に用いた考えを網羅している机上理論ではなく筆者の実践経験が活きた記述が豊富

Slide 28

Slide 28 text

whyがわかると開発上さまざまな恩恵がある

Slide 29

Slide 29 text

whyの記述に着目してミノ駆動本を読もう

Slide 30

Slide 30 text

実際に手を動かして試してみるとよりwhyの理解が進む泥臭い製品コードを題材に設計の練習をしてみよう（詳細は17章にて）

Slide 31

Slide 31 text

深める② 上位技術書をより深く学べる、活用できる

Slide 32

Slide 32 text

『リファクタリング』や『レガシーコード改善ガイド』などにはさまざまな設計テクニックがある

Slide 33

Slide 33 text

書籍『リファクタリング』の例メソッド移動『新装版リファクタリング既存のコードを安全に改善する』著 :Martin Fowler、訳:児玉公信、友野晶夫、平澤章、梅澤真史、2014年刊行、オーム社、p.142より引用 aMethod()がclass2のことばかり気にするようなロジックであればclass2へ移動

Slide 34

Slide 34 text

書籍『リファクタリング』の例メソッド移動わーい、リファクタリングできたぞーコードがきれいになったぞー

Slide 35

Slide 35 text

書籍『リファクタリング』の例メソッド移動 ……？？このあとどうすればいいんだろう？どういう構造まで改善できればいいんだろう？

Slide 36

Slide 36 text

手法だけ表面的に真似るだけで中途半端な設計に陥りがち設計のゴールがわからない

Slide 37

Slide 37 text

３章クラス設計　基本の「き」を徹底解説インスタンス変数は不変に完全コンストラクタで必ず初期化メソッドは必ず自身のインスタンス変数を使う副作用を生じないメソッド不正状態に陥らない、常に正常なインスタンスのみが存在可能な、自己防衛責務を備えた構造

Slide 38

Slide 38 text

常に正常なクラスのみでシステム内を満たすよう設計するこれが変更に強いシステム！

Slide 39

Slide 39 text

つまりクラス設計のゴールがわかる

Slide 40

Slide 40 text

書籍『リファクタリング』など上位技術書のノウハウについてより深く意味を理解できるようになるより活用できるようになる

Slide 41

Slide 41 text

深める③ ドメイン駆動設計の理解が進む

Slide 42

Slide 42 text

本書は大部分においてDDDの影響を受けています

Slide 43

Slide 43 text

DDD実践上必要な基本的な考え方を学べます

Slide 44

Slide 44 text

【ユビキタス言語】意図や目的を共有する言葉ドメインモデル境界付けられたコンテキストの設計に密接に関わる

Slide 45

Slide 45 text

「野菜を加工する」何を思い浮かべますか？

Slide 46

Slide 46 text

野菜炒め

Slide 47

Slide 47 text

精霊馬

Slide 48

Slide 48 text

言葉ひとつとっても意味が違う

Slide 49

Slide 49 text

目的によって意味に違いが生じる料理目的お供え目的

Slide 50

Slide 50 text

ドメインモデルドメインモデルは更新モデル更新とはデータの加工や変換ドメインモデルには加工対象のデータやロジックをカプセル化商品 ID 商品名商品コード価格

Slide 51

Slide 51 text

在庫管理配送注文商品審査 ECサイト商品モデルあらゆる問題に対応可能な、たったひとつの万能な商品モデルはありえるのだろうか？？

Slide 52

Slide 52 text

クソコード動画「一枚岩モデル」 https://twitter.com/MinoDriven/status/1590181987910029314

Slide 53

Slide 53 text

統一的な一枚岩モデルにより生じる弊害 ● どの状況で何のデータが使われるのか分かりにくくなる ● どの状況でどんな振る舞いが期待されるのか分かりにくくなる ○ 状況によって守るべき不変条件が異なる ● 言葉やデータの意味が多義的になり、混乱をきたす ○ 混乱によりエンバグしやすい ○ データのフォーマットが状況によって違うケースもある ● 多くのあらゆるロジックと密結合になる ○ 保守や仕様変更時の影響範囲分析に莫大な労力を要する

Slide 54

Slide 54 text

在庫管理配送注文商品審査 ECサイト商品モデル審査用に特化商品モデル商品モデル商品モデル注文用に特化配送用に特化在庫管理用に特化従って各問題領域それぞれに対して専門で解決する、目的特化型モデルを設計するのが良い

Slide 55

Slide 55 text

商品審査商品審査コンテキスト商品モデル注文注文コンテキスト商品モデル在庫管理在庫管理コンテキスト商品モデル配送配送コンテキスト商品モデル各特化型モデルは、それぞれ適用可能な範囲が異なるこの範囲をシステム境界として定めたのが境界付けられたコンテキスト

Slide 56

Slide 56 text

在庫目的配送目的商品モデル商品モデル DRY原則に従えば、目的ごとに特化型モデルを設計するのは自然なこと各モデルの適用範囲として境界付けられたコンテキストを定めるのも自然なこと

Slide 57

Slide 57 text

商品審査商品審査コンテキスト審査品目注文注文コンテキスト注文品在庫管理在庫管理コンテキスト在庫品目配送配送コンテキスト配送品意図や目的は背後に隠れてて本当に分かりにくいし認知困難だからはじめから目的駆動で名前設計する（詳しくは拙著『良いコード/悪いコードで学ぶ設計入門』）

Slide 58

Slide 58 text

● 10章：名前設計 ○ ユビキタス言語の操り方を解説 ● 13章：モデリング ○ ドメインモデリングを解説 ● 15章：設計の意義と設計への向き合い方 ○ DDDの戦略面を解説その他、さまざまな箇所にDDDのエッセンスを散りばめている

Slide 59

Slide 59 text

ミノ駆動本を読むと DDDに必要な基礎を無理なく自然に身につけられる

Slide 60

Slide 60 text

ミノ駆動本は様々な技術書への足がかりになる

Slide 61

Slide 61 text

深める④ アーキテクトとしての第一歩

Slide 62

Slide 62 text

ソフトウェアアーキテクチャ　とは望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったもの。『Design It! - プログラマーのためのアーキテクティング入門』著 :Michael Keeling、訳:島田浩二、2019年刊行、オライリージャパン、 p.8より引用この設計判断を担う人がソフトウェアアーキテクト

Slide 63

Slide 63 text

出典：経産省『IT人材の最新動向と将来設計に関する調査結果』（ 2016）アーキテクトが全然足りない！体感レベルで人材不足

Slide 64

Slide 64 text

アーキテクトキャリアの利点 ● 利点１：ブルーオーシャン市場 ○ 圧倒的に人手不足 ○ 努力は必要だが、努力次第でちゃんとこの上級職に就ける ● 利点２：スキルがあまり陳腐化しない ○ フロントは特に陳腐化が激しい ○ 他の技術と比べ、ソフトウェア工学は長きにわたって活用可能 ● 利点３：どのIT分野でも活躍できる ○ ソフトウェア工学に垣根はない ○ Web系に限らず、組み込み系でもどの分野でも活躍できる ○ エンジニアとしての生存性が高まる！（私がその証拠）

Slide 65

Slide 65 text

ソフトウェアアーキテクトの仕事 ● エンジニアリングの観点から問題を定義する ○ 利害関係者と協力し、ソフトウェアのビジネス目標と要求を定義する ● システムを分割し、責務を割り当てる ● 広い視野を持って全体に目を向け続ける ● 品質特性間のトレードオフを決定する ● 技術的負債を管理する ● チームのアーキテクチャスキルを高める『Design It! - プログラマーのためのアーキテクティング入門』著 :Michael Keeling、訳:島田浩二、2019年刊行、オライリージャパン、 p.4-7より引用

Slide 66

Slide 66 text

Slide 67

Slide 67 text

おまけ・補足

Slide 68

Slide 68 text

『リーダブルコード』との差異「タイトルに『コード』とあるから『リーダブルコード』と同じなのでは？」といったコメントがたびたび散見されますが……だいぶ違います！！リーダブルコード：命名やコードブロックの整え方など、読みやすさを中心に解説ミノ駆動本：仕様変更時にバグを埋め込みにくくし、素早く変更できるようになるための構造設計を解説 10章名前設計では命名を取り扱っているが、読みやすさというより責務や構造定義のための手法として解説

Slide 69

Slide 69 text

『バグハンター2 REBOOT』 https://game.nicovideo.jp/atsumaru/games/gm22047 副教材的な位置づけです、ぜひ遊んでね無料。 PC、スマホでプレイ可。

Slide 70

Slide 70 text

ミノ駆動本に登場するアンチパターンがモンスターとして登場

Slide 71

Slide 71 text

さまざまな設計スキルや設計原則が登場（ガチめ）

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

技術的負債による損失は国内全体で国家予算に匹敵するレベル IT成長のために負債解消は喫緊の課題

Slide 74

Slide 74 text

しかし技術的負債そのものや解決方法としての設計は世の中的に認知が不十分ですもっと認知度を高める必要があります