Refactoring

リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの まず整理：構造と概念の違い 構造の変更 概念の変更 なぜこの区別が重要なのか？ なぜ通常は「構造 → 概念」なのか？ ① 変更の安全性 ② デバッグのしやすさ ③ 複雑性の増幅 実務での使い分け（私の優先順位） 第1段階：可視化 第2段階：構造整理 第3段階：責務の明確化 第4段階：概念強化 まとめ リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの 私は最近の失敗から、大きな学びを得ました。 それは、 リファクタリングには二種類ある ということです。 構造 を変えるリファクタリング 概念 を変えるリファクタリング この区別を意識していなかったことが、バグの原因でした。 この記事では、自分なりに整理した実務的な優先順位と共にまとめます。 まず整理：構造と概念の違い 構造の変更 関数抽出 共通化 重複削除 名前変更 ネスト解消 責務分離 振る舞いは変えない（意味は同じ） これは「コードの形」を整える作業です。 概念の変更 Boolean → sealed class nullable → 非null設計 エラー型明確化 状態遷移の型化 エンティティ再設計 ドメインモデル再定義 責務の再解釈 プログラムが表現する「意味」が変わる これは「コードが何を表現しているか」を変える作業です。 なぜこの区別が重要なのか？ 私は「成功」という概念を Boolean で扱っていました。 しかし実際には： 作成成功 更新成功 失敗 という複数の意味がありました。 Boolean に押し込めたことで、 意味の差が見えなくなり、無意識に共通化してしまった のです。 ...