clj-refactor

メカニズムとポリシーの分離を改善できる箇所がないか、以下の原則に従って、指定されたファイルまたはディレクトリを調査します。

調査対象

Arne Brasseur の定義を使用します。

メカニズムとは、次のようなコードです。

• 特定の考え方に偏らず、コンテキストに依存しない
• 異なるビジネスドメインで再利用できる
• 単独で簡単にテストできる
• 安定しており、時間の経過による変更が少ない

ポリシーとは、次のようなコードです。

• 特定の考え方に基づき、現在のビジネス上の判断を反映している
• コンテキストに依存し、特定のドメインに結び付いている
• 頻繁に変更されることが想定される

両者の違いは、コードが 何を するかではなく、どのように 書かれているかにあります。 コードをこのスペクトルの両端に近づけることが目標です。

診断のヒューリスティクス

コードがスペクトルのどこに位置するかを評価する際は、次の点を確認します。

• このコードはすべての依存関係を明示的なパラメーターとして受け取っていますか。それともデフォルト値、グローバル変数、暗黙のコンテキストに依存していますか。 （明示的であるほど、メカニズムに近くなります）

• このロジックを別の場所で再利用する場合、異なるパラメーターを渡して呼び出しますか。それともコピーして変更しますか。 （パラメーターによる再利用はメカニズム、コピー＆ペーストによる再利用はポリシーです）

• このコードが表しているのは、安定した技術的な事実ですか。それとも現在のビジネス上の判断ですか。ビジネス上の判断はポリシーに属します。

• 値がどの程度ハードコードされていますか。ハードコードされた定数は、ポリシーがメカニズムに入り込んでいる兆候です。

• このコードは明示性（シンプルさ）よりも利便性（手軽さ）を優先していますか。利便性を重視したデフォルト値は、多くの場合、ポリシーがメカニズムに入り込んでいる兆候です。

タスク

調査したファイルまたはモジュールごとに、次の項目を報告します。

1. 混在したコード — メカニズムとポリシーが絡み合っている関数またはモジュール。何が混在しているか、境界をどこに引くべきかを説明します。

2. 抽出候補 — 現在ポリシーコードに埋め込まれているメカニズムのうち、別のモジュールまたはライブラリに抽出できるもの。各候補がメカニズムに該当する理由（コンテキストに依存せず、安定しており、再利用できること）を説明します。

3. 配置場所が不適切なポリシー — 低レベルのメカニズムに属するべき箇所に入り込んだビジネスロジック。隠れた前提と、それが属するべき場所を説明します。

4. リファクタリング案 — 各指摘について、具体的なリファクタリングを提案します。原則を述べるだけでなく、変更前と変更後の構成を示します。

制約

• 時期尚早なリファクタリングは避けてください。少なくとも2つの異なるユースケースでパターンが確認された場合に限り、抽出を提案します。
• 既存の動作を維持してください。これは構造をリファクタリングするものであり、ビジネスロジックを書き直すものではありません。
• 提案は実際のコードに基づくものにしてください。現在のコードベースに根拠のない抽象化は提案しないでください。