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

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

MinoDriven
November 24, 2022

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

こちらのイベントで用いたスライドです。

『良いコード/悪いコードで学ぶ設計入門』を一歩深める読み方 - FwLibrary #11
https://forkwell.connpass.com/event/264759/

動画のアーカイブはこちら。
https://youtu.be/_qXG06v8HAI

MinoDriven

November 24, 2022
Tweet

More Decks by MinoDriven

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

  3. まずはみなさん

    View Slide

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

    View Slide

  5. ここで働いています

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  9. 『良いコード/悪いコードで学ぶ設計入門』
    繁体字(台湾)版
    🎉翻訳出版 決定🎉
    韓国語版

    View Slide

  10. 本書の特徴

    View Slide

  11. 以下でお困りではないですか?
    どこかのコードを変更すると別の箇所でバグが発生する
    変更の影響がありそうな箇所を、あちこち探し回らなければならなくなった
    コードを読んでるだけで日が暮れてしまった
    仕様変更やバグ修正に何日も費やしてしまった
    でも何が問題か分からない
    どう直せばいいのか分からない

    View Slide

  12. 変更容易性
    仕様変更時、なるべくバグを埋め込まず、素早く正確にロジック変更できるかを指し示す
    度合い
    ソフトウェア品質特性の一種
    変更容易性が低いと、バグを埋め込みやすくなったり、変更に何日もかかったり、といっ
    た弊害が生じる
    変更容易性の低いコードをレガシーコード、技術的負債と呼ぶ

    View Slide

  13. 変更容易性の設計手法を解説する入門書
    変更容易性を高める設計を解説
    バグを埋め込みにくく、素早く正確にロジック変更できるようになる
    開発生産性が向上する
    膨大なサンプルコード、事例を用いて解説
    さまざまなケースに対応できるようになる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. この本の通りに設計するだけで
    だいたいの技術的負債は解決!

    View Slide

  18. 設計スキルの谷
    入門書

    View Slide

  19. 入門書
    初級と中級の間にかける橋

    View Slide

  20. 背後にいろんな技術書のエッセンスがある

    View Slide

  21. ミノ駆動本を読むと
    より上位の技術書を理解するのに必要な
    考え方を学ぶことができる
    今日はそういうお話

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. 野菜炒め

    View Slide

  47. 精霊馬

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. おまけ・補足

    View Slide

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

    10章名前設計では命名を取り扱っているが、読みやすさというより責務や構造定義のた
    めの手法として解説

    View Slide

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

    View Slide

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

    View Slide

  71. さまざまな設計スキルや設計原則が登場(ガチめ)

    View Slide

  72. View Slide

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

    View Slide

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

    View Slide

  75. あなたの1票が多くの人々を救います

    View Slide

  76. ご清聴ありがとうございました

    View Slide