私はこれまで、DDD（ドメイン駆動設計）について、「ユーザーインターフェース・アプリケーション・ドメイン・インフラがある」「ビジネスロジックはドメインに置こう」といった基本概念は理解しているつもりでした。
しかし、それは完全に「言葉だけ知って満足している」状態でした。
AIのコードをレビューできない「ハリボテの知識」
その事実を突きつけられたのは、AIが実装したコードをレビューした時です。
AIが自動生成したコードに対して、
「モデルのバリデーションは本当にここに置くべきか？」
「ここはValueObjectにするべきか？それともEntityにするべきか？」
といった判断を迫られた時、私は瞬時に決断できませんでした。ましてや、脳内で明確な回答を出すことなど不可能です。
さらに、「インフラ層」と一言で言っても、そこにExcelやファイルのテンプレートを置くべきなのかどうかすら悩んでしまう始末。悩んでいる時点で、概念を咀嚼して自分のものに出来ていない証拠です。
結果として、AIが書いたコードを数週間後にAIの支援なしでリーディングしたり修正したりする際、調査に膨大な時間がかかってしまいました。
AIの支援が切れた途端に「ポンコツ」になった自分
もっと絶望的だったのは、GitHub Copilotの制限の都合でAIの支援が一時的になくなった時のことです。
それまで月に10万行以上コードを書いていたのに、一気に生産性が落ち、1日1000行も書けなくなりました。AIの支援がないと、さも「ちゃんとしたDDDの設計原則に従っている」はずの自分のコードに対して、書き方にまったく自信が持てないのです。
調査にばかり時間が掛かり、文字通り「ポンコツ」になりました。
言葉を知っているだけで、本質的な設計原則が身についていなければ、AIという補助輪が外れた瞬間に立ち転けします。
もっと調べに調べろ、深掘りしろ
この強烈な挫折を経て、私は「もっとAIの支援がなくても自分で判断できるようになりたい」と強く思いました。
ドメインやインフラといった概念を、ただのバズワードとしてではなく、実務のコードの中でどう振る舞うべきなのか、改めて深掘りしていきます。
自分の言葉とコードで説明できるようになるまで咀嚼しなければならないと、強烈に痛感した出来事でした。
コメント