https://design.okuda-studio.com/tags/refactoring/Recent content in Refactoring on 設計で、迷わなくなるために | 奥田智紘Hugo -- 0.159.2jaWed, 04 Mar 2026 13:00:00 +0900https://design.okuda-studio.com/posts/0013-refactoring-type/Wed, 04 Mar 2026 13:00:00 +0900https://design.okuda-studio.com/posts/0013-refactoring-type/<ul> <li><a href="#%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AB%E3%81%AF%E4%BA%8C%E7%A8%AE%E9%A1%9E%E3%81%82%E3%82%8B--%E6%A7%8B%E9%80%A0%E3%82%92%E5%A4%89%E3%81%88%E3%82%8B%E3%82%82%E3%81%AE%E3%81%A8%E6%A6%82%E5%BF%B5%E3%82%92%E5%A4%89%E3%81%88%E3%82%8B%E3%82%82%E3%81%AE">リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの</a></li> <li><a href="#%E3%81%BE%E3%81%9A%E6%95%B4%E7%90%86%E6%A7%8B%E9%80%A0%E3%81%A8%E6%A6%82%E5%BF%B5%E3%81%AE%E9%81%95%E3%81%84">まず整理：構造と概念の違い</a> <ul> <li><a href="#%E6%A7%8B%E9%80%A0%E3%81%AE%E5%A4%89%E6%9B%B4">構造の変更</a></li> <li><a href="#%E6%A6%82%E5%BF%B5%E3%81%AE%E5%A4%89%E6%9B%B4">概念の変更</a></li> </ul> </li> <li><a href="#%E3%81%AA%E3%81%9C%E3%81%93%E3%81%AE%E5%8C%BA%E5%88%A5%E3%81%8C%E9%87%8D%E8%A6%81%E3%81%AA%E3%81%AE%E3%81%8B">なぜこの区別が重要なのか？</a></li> <li><a href="#%E3%81%AA%E3%81%9C%E9%80%9A%E5%B8%B8%E3%81%AF%E6%A7%8B%E9%80%A0--%E6%A6%82%E5%BF%B5%E3%81%AA%E3%81%AE%E3%81%8B">なぜ通常は「構造 → 概念」なのか？</a> <ul> <li><a href="#-%E5%A4%89%E6%9B%B4%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7">① 変更の安全性</a></li> <li><a href="#-%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%81%AE%E3%81%97%E3%82%84%E3%81%99%E3%81%95">② デバッグのしやすさ</a></li> <li><a href="#-%E8%A4%87%E9%9B%91%E6%80%A7%E3%81%AE%E5%A2%97%E5%B9%85">③ 複雑性の増幅</a></li> </ul> </li> <li><a href="#%E5%AE%9F%E5%8B%99%E3%81%A7%E3%81%AE%E4%BD%BF%E3%81%84%E5%88%86%E3%81%91%E7%A7%81%E3%81%AE%E5%84%AA%E5%85%88%E9%A0%86%E4%BD%8D">実務での使い分け（私の優先順位）</a> <ul> <li><a href="#%E7%AC%AC1%E6%AE%B5%E9%9A%8E%E5%8F%AF%E8%A6%96%E5%8C%96">第1段階：可視化</a></li> <li><a href="#%E7%AC%AC2%E6%AE%B5%E9%9A%8E%E6%A7%8B%E9%80%A0%E6%95%B4%E7%90%86">第2段階：構造整理</a></li> <li><a href="#%E7%AC%AC3%E6%AE%B5%E9%9A%8E%E8%B2%AC%E5%8B%99%E3%81%AE%E6%98%8E%E7%A2%BA%E5%8C%96">第3段階：責務の明確化</a></li> <li><a href="#%E7%AC%AC4%E6%AE%B5%E9%9A%8E%E6%A6%82%E5%BF%B5%E5%BC%B7%E5%8C%96">第4段階：概念強化</a></li> </ul> </li> <li><a href="#%E3%81%BE%E3%81%A8%E3%82%81">まとめ</a></li> </ul> <h1 id="リファクタリングには二種類ある--構造を変えるものと概念を変えるもの">リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの</h1> <p>私は最近の失敗から、大きな学びを得ました。</p> <p>それは、</p> <blockquote> <p>リファクタリングには二種類ある</p> </blockquote> <p>ということです。</p> <ul> <li><strong>構造</strong> を変えるリファクタリング</li> <li><strong>概念</strong> を変えるリファクタリング</li> </ul> <p>この区別を意識していなかったことが、バグの原因でした。</p> <p>この記事では、自分なりに整理した実務的な優先順位と共にまとめます。</p> <hr> <h1 id="まず整理構造と概念の違い">まず整理：構造と概念の違い</h1> <h2 id="構造の変更">構造の変更</h2> <ul> <li>関数抽出</li> <li>共通化</li> <li>重複削除</li> <li>名前変更</li> <li>ネスト解消</li> <li>責務分離</li> </ul> <p><strong>振る舞いは変えない（意味は同じ）</strong></p> <p>これは「コードの形」を整える作業です。</p> <hr> <h2 id="概念の変更">概念の変更</h2> <ul> <li>Boolean → sealed class</li> <li>nullable → 非null設計</li> <li>エラー型明確化</li> <li>状態遷移の型化</li> <li>エンティティ再設計</li> <li>ドメインモデル再定義</li> <li>責務の再解釈</li> </ul> <p><strong>プログラムが表現する「意味」が変わる</strong></p> <p>これは「コードが何を表現しているか」を変える作業です。</p> <hr> <h1 id="なぜこの区別が重要なのか">なぜこの区別が重要なのか？</h1> <p>私は「成功」という概念を Boolean で扱っていました。</p> <p>しかし実際には：</p> <ul> <li>作成成功</li> <li>更新成功</li> <li>失敗</li> </ul> <p>という複数の意味がありました。</p> <p>Boolean に押し込めたことで、 <strong>意味の差が見えなくなり、無意識に共通化してしまった</strong> のです。</p>