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

AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-b...

AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code

こちらのイベントの登壇資料です

AI時代の「良いコード/悪いコードで学ぶ設計入門」「ドメイン駆動設計をはじめよう」
https://forkwell.connpass.com/event/356295/

Avatar for MinoDriven

MinoDriven

July 10, 2025
Tweet

More Decks by MinoDriven

Other Decks in Programming

Transcript

  1. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部

    DeveloperProductivityGroup DMMプラットフォームの設計を改善し 開発生産性向上を図るのがミッション 2
  2. © DMM 7つのリニューアル! 1. 【変更】凝集度、結合度からカプセル化、関心の分離へ 2. 【加筆】インターフェースと実装の分離 3. 【変更】interfaceの解説を改善 4.

    【加筆】インターフェースと実装の分離にもとづいたinterface設計 5. 【加筆】アンカリング効果 6. 【加筆】ジョシュアツリーの法則 7. 【加筆】説明による設計スキルアップ 6
  3. © DMM 凝集度が高くても変更容易性が低いケース 8 class Util { // このaddメソッドは機能的凝集の構造 //

    しかしMoneyクラスに定義されていないので変更容易性は低い static Money add(Money money1, Money money2) { if (!money1.currency.equals(money2.currency)) { throw new IllegalArgumentException("通貨単位が違います。"); } Money added = new Money(); added.amount = money1.amount + money2.amount; added.currency = money1.currency; return added; } } // 金額を表現するクラス class Money { int amount; // 金額値 Currency currency; // 通貨単位 }
  4. © DMM 【環境】 Cursor + Claude 4 sonnet 【以下の品質について検証】 •

    技術的負債の分析 • リファクタリング • テストコード実装 20
  5. © DMM テストコード実装 【指示の仕方】 「このコードにテストコードを実装して」と雑に指示 【所感】 • テストコードの実装は得意らしく、 雑な指示でもそれなりの品質のテストコードを書いてくれる。 •

    テストケースのヌケモレはたびたび発生する。 • 複数の要件を検証するテストケースを実装することがある (このようなテストは仕様変更に脆い)。 23
  6. © DMM 言葉の汚染(意味の希薄化) 生成AIの原理は「連想」。 ある特定の単語に別の単語が強く関連付いているために、 回答が不正確になるケースがあります。 25 言葉 ハルシネーションの例 リファクタリング、

    技術的負債、 変更容易性 指示していない「責務」という観点を持ち出してくる。 AI自身もよく分かっていないようで、負債の分析や改 善提案の正確性が悪化する。 ドメイン駆動設計 非推奨なDomainServiceを頻繁に提案してくるように なる。鵜呑みにすると品質が悪化する。 このような現象を言葉の汚染とミノ駆動は呼んでいます。
  7. © DMM 31 静的解析ツールとの負債分析観点比較 静的解析ツールは「コードの意図」がわかりません。 一方、生成AIは意図を推論できます。 生成AIだからこそ可能な負債分析です。 一般的な静的解析ツールの分析観点 コード行数 サイクロマチック複雑度

    コード重複 引数の数 etc.. バグサーチャーの分析観点 カプセル化 ドメインロジックの関心の分離 ドメインモデル完全性 技術レイヤ間の関心の分離 各設計パターン毎の設計要件 interface設計 etc..
  8. © DMM スケールする負債分析の質と量 例えば約400行ほどのソースコードの負債を洗いざらい分析する場合 • ミノ駆動の目視 : 約15〜30分(ドメイン知識に依存) • バグサーチャー

    : 約1分 私は変更容易性やリファクタリングを専門としていますが、 私とほぼ同等の精度で、かつ10倍以上の生産性で分析できています。 しかも誰でもバグサーチャーを使えるので、 お手軽に「ミノ駆動の分身」を増やせる体制に。 変更容易性の専門知識のおかげで実現できたと言えます。 32
  9. © DMM 契約による設計とテストコード 契約による設計とは、正確性の向上を目的に バートランド・メイヤー氏が考案した設計の方法論。 以下の3条件から構成されます。 • 事前条件:メソッド開始時に保証されるべき条件 • 事後条件:メソッド終了時に保証されるべき条件

    • 不変条件:常に維持されるべき条件 モジュールの機能適合性を保証するテストはこの3条件の検証が基本。 つまり生成AIに高品質なテストコードを実装させるには、 契約による設計を踏まえる必要があります。 33
  10. © DMM 契約による設計に基づくプロンプト実装 34 # 役割 あなたは以下の専門家である - テストコード -

    契約による設計(事前条件、事後条件、不変条件) # 目的 テストコード実装 # 制約 - メソッドの事前条件、事後条件、不変条件を検証するテストであること - Given-When-Thenパターンに基づいて実装すること # テスト対象 (ここにテスト対象のメソッドを指定する)
  11. © DMM スケールするテストコード実装の質と量 約100行のコードにテストを書く場合、分析も含めて • ミノ駆動の実装 : 20-60分??(ドメイン知識に依存) • 前述のプロンプト:

    1分以内 数十倍のオーダーで高速化! 抜け漏れもなく、テストと検証対象が1:1になっているので、 テストコードの品質も良好。 36