コード簡潔化

Claude Code Simplifier プラグインにインスパイアされています。ここではモデル非依存で、プロセス駆動型のスキルとしてあらゆるAIコーディングエージェント向けに適応させています。

概要

動作を保持したまま複雑さを削減することでコードを簡潔化します。目標は行数を減らすことではなく、読みやすく、理解しやすく、修正しやすく、デバッグしやすいコードにすることです。すべての簡潔化は単純なテストに合格する必要があります。「新しいチームメンバーは元のコードより速くこれを理解できるだろうか?」

使用時機

• 機能が動作してテストが合格した後、実装が必要以上に重い場合
• コードレビュー時に可読性や複雑性の問題が指摘された場合
• 深くネストされたロジック、長い関数、不明確な名前に遭遇した場合
• 時間的圧力の下で書かれたコードをリファクタリングする場合
• 関連するロジックが複数ファイルに散在している場合
• 変更をマージした後、重複や矛盾が生じた場合

使用してはいけない場合:

• コードが既にクリーンで読みやすい場合—単に簡潔化のために簡潔化しない
• コードが何をするかまだ理解していない場合—簡潔化する前に理解する
• コードが性能クリティカルで、「より簡潔な」バージョンが測定可能に遅い場合
• モジュール全体を書き直そうとしている場合—使い捨てコードの簡潔化は努力の無駄

5つの原則

1. 動作を完全に保持する

コードが何をするかは変えず、どのように表現するかだけを変えます。すべての入力、出力、副作用、エラー動作、エッジケースは同一のままである必要があります。簡潔化が動作を保持するかどうか確信がない場合は、変更しないでください。

すべての変更の前に確認してください:
→ すべての入力に対して同じ出力を生成しますか?
→ 同じエラー動作を維持していますか?
→ 同じ副作用と順序を保持していますか?
→ すべての既存テストは修正なしで合格しますか?

2. プロジェクト規約に従う

簡潔化とは、外部の好みを押し付けるのではなく、コードベースとの一貫性を高めることです。簡潔化する前に:

1. CLAUDE.md / プロジェクト規約を読む
2. 隣接するコードが類似パターンをどのように処理しているかを研究する
3. プロジェクトのスタイルに合わせる:
   - インポート順序とモジュールシステム
   - 関数宣言スタイル
   - 命名規約
   - エラーハンドリングパターン
   - 型注釈の深さ

プロジェクト一貫性を破る簡潔化は簡潔化ではなく、チャーンです。

3. 巧妙さより明確さを優先する

コンパクト版を理解するのに一呼吸必要な場合、明示的なコードはコンパクトなコードより優れています。

// 不明確: 密集した三項演算子チェーン
const label = isNew ? 'New' : isUpdated ? 'Updated' : isArchived ? 'Archived' : 'Active';

// 明確: 読みやすいマッピング
function getStatusLabel(item: Item): string {
  if (item.isNew) return 'New';
  if (item.isUpdated) return 'Updated';
  if (item.isArchived) return 'Archived';
  return 'Active';
}

// 不明確: インラインロジック付きチェーン化されたreduces
const result = items.reduce((acc, item) => ({
  ...acc,
  [item.id]: { ...acc[item.id], count: (acc[item.id]?.count ?? 0) + 1 }
}), {});

// 明確: 名前付き中間ステップ
const countById = new Map<string, number>();
for (const item of items) {
  countById.set(item.id, (countById.get(item.id) ?? 0) + 1);
}

4. バランスを保つ

簡潔化には失敗モードがあります。過度の簡潔化です。これらの罠に注意してください:

• 積極的なインライン化 —概念に名前を与えたヘルパーを削除すると、呼び出し元がより読みにくくなる
• 関連のないロジックの組み合わせ —2つのシンプルな関数を1つの複雑な関数にマージすることは簡潔化ではない
• 「不要な」抽象化の削除 —いくつかの抽象化は複雑さではなく、拡張性やテスト可能性のために存在する
• 行数の最適化 —行数が少ないことが目標ではなく、理解の容易さが目標

5. 変更範囲に限定する

デフォルトでは最近修正されたコードの簡潔化に限定します。明示的に範囲を広げるよう依頼されない限り、関連のないコードの自動リファクタリングは避けてください。範囲外の簡潔化はdiffにノイズを生じさせ、意図しない回帰のリスクがあります。

簡潔化プロセス

ステップ1: 変更する前に理解する(チェスタートンの柵)

何かを変更または削除する前に、それが存在する理由を理解します。これはチェスタートンの柵です。道路に柵があり、そこにある理由を理解していない場合、それを取り壊さないでください。まず理由を理解してから、その理由がまだ有効かどうかを決定します。

簡潔化する前に、以下に答えてください:
- このコードの責任は何ですか?
- 何がこれを呼び出していますか? これは何を呼び出していますか?
- エッジケースとエラーパスは何ですか?
- 期待される動作を定義するテストはありますか?
- このように書かれた可能性がある理由は何ですか?(パフォーマンス? プラットフォーム制約? 歴史的な理由?)
- git blameを確認してください: このコードの元のコンテキストは何でしたか?

これらに答えられない場合、簡潔化の準備ができていません。まず詳細を読んでください。

ステップ2: 簡潔化の機会を特定する

これらのパターンをスキャンしてください—各パターンは曖昧な「においい」ではなく、具体的な信号です:

構造的複雑性:

パターン	信号	簡潔化
深いネスト(3段階以上)	制御フローが追いにくい	条件をガード句またはヘルパー関数に抽出する
長い関数(50行以上)	複数の責任	フォーカスされた関数に分割し、説明的な名前を付ける
ネストされた三項演算子	メンタルスタックが必要	if/elseチェーン、switch、またはルックアップオブジェクトに置き換える
ブール値パラメータフラグ	doThing(true, false, true)	オプションオブジェクトまたは個別関数に置き換える
繰り返される条件分岐	同じifチェックが複数箇所	名前の良い述語関数に抽出する

命名と可読性:

パターン	信号	簡潔化
ジェネリック名	data、result、temp、val、item	コンテンツを説明する名前に変更: userProfile、validationErrors
略名	usr、cfg、btn、evt	略語が一般的でない限り、フルワードを使用(id、url、apiは例外)
誤解を招く名前	getという名前だが状態も変更する関数	実際の動作を反映する名前に変更する
「何」を説明するコメント	// increment counter の上に count++	コメントを削除—コードは十分明確
「なぜ」を説明するコメント	// API はロード下では不安定なため、リトライします	これらは保持—コードが表現できない意図を伝える

冗長性:

パターン	信号	簡潔化
重複したロジック	複数箇所に同じ5行以上	共有関数に抽出する
デッドコード	到達不可能な分岐、未使用の変数、コメントアウトされたブロック	削除(本当にデッドであることを確認後)
不要な抽象化	値を追加しないラッパー	ラッパーをインライン化し、基本的な関数を直接呼び出す
過度に設計されたパターン	ファクトリーのファクトリー、1つの戦略のみの戦略パターン	シンプルな直接的なアプローチに置き換える
冗長な型アサーション	既に推論されている型へのキャスト	アサーションを削除する

ステップ3: 変更を段階的に適用する

一度に1つの簡潔化を行います。各変更後にテストを実行します。リファクタリング変更は機能追加またはバグ修正の変更と別に提出してください。 リファクタリングと機能追加の両方を行うPRは2つのPRです—分割してください。

各簡潔化について:
1. 変更を加える
2. テストスイートを実行する
3. テストが合格 → コミット(または次の簡潔化に続ける)
4. テストが失敗 → リバートして再検討する

複数の簡潔化をテストなしで1つの変更に組み込むことは避けてください。何か壊れた場合、どの簡潔化が原因かを知る必要があります。

500行ルール: リファクタリングが500行を超える場合、手動で変更を加えるのではなく、自動化(codemod、sedスクリプト、ASTトランスフォーム)に投資してください。この規模の手動編集はエラーが起こりやすく、レビューが疲れます。

ステップ4: 結果を検証する

すべての簡潔化の後、全体を一歩下がって評価します:

変更前と後を比較する:
- 簡潔化されたバージョンは本当に理解しやすいですか?
- コードベースと矛盾する新しいパターンを導入しましたか?
- diffはクリーンでレビュー可能ですか?
- チームメートはこの変更を承認しますか?

「簡潔化された」バージョンの方が理解またはレビューが難しい場合は、リバートします。すべての簡潔化の試みが成功するわけではありません。

言語別ガイダンス

TypeScript / JavaScript

// 簡潔化: 不要な非同期ラッパー
// 変更前
async function getUser(id: string): Promise<User> {
  return await userService.findById(id);
}
// 変更後
function getUser(id: string): Promise<User> {
  return userService.findById(id);
}

// 簡潔化: 冗長な条件付き代入
// 変更前
let displayName: string;
if (user.nickname) {
  displayName = user.nickname;
} else {
  displayName = user.fullName;
}
// 変更後
const displayName = user.nickname || user.fullName;

// 簡潔化: 手動配列構築
// 変更前
const activeUsers: User[] = [];
for (const user of users) {
  if (user.isActive) {
    activeUsers.push(user);
  }
}
// 変更後
const activeUsers = users.filter((user) => user.isActive);

// 簡潔化: 冗長なブール値リターン
// 変更前
function isValid(input: string): boolean {
  if (input.length > 0 && input.length < 100) {
    return true;
  }
  return false;
}
// 変更後
function isValid(input: string): boolean {
  return input.length > 0 && input.length < 100;
}

Python

# 簡潔化: 冗長なディクショナリ構築
# 変更前
result = {}
for item in items:
    result[item.id] = item.name
# 変更後
result = {item.id: item.name for item in items}

# 簡潔化: 早期リターンで条件分岐をネストする
# 変更前
def process(data):
    if data is not None:
        if data.is_valid():
            if data.has_permission():
                return do_work(data)
            else:
                raise PermissionError("No permission")
        else:
            raise ValueError("Invalid data")
    else:
        raise TypeError("Data is None")
# 変更後
def process(data):
    if data is None:
        raise TypeError("Data is None")
    if not data.is_valid():
        raise ValueError("Invalid data")
    if not data.has_permission():
        raise PermissionError("No permission")
    return do_work(data)

React / JSX

// 簡潔化: 冗長な条件付きレンダリング
// 変更前
function UserBadge({ user }: Props) {
  if (user.isAdmin) {
    return <Badge variant="admin">Admin</Badge>;
  } else {
    return <Badge variant="default">User</Badge>;
  }
}
// 変更後
function UserBadge({ user }: Props) {
  const variant = user.isAdmin ? 'admin' : 'default';
  const label = user.isAdmin ? 'Admin' : 'User';
  return <Badge variant={variant}>{label}</Badge>;
}

// 簡潔化: 中間コンポーネント経由のプロパティドリリング
// 変更前 - コンテキストまたはコンポジションが解決できるかどうかを検討してください。
// これは判断を必要とします—自動リファクタリングではなく、フラグを立てます。

よくある言い訳

言い訳	現実
「動作しているので、触る必要はない」	読みにくい動作コードは、壊れたときに修正が難しくなります。今簡潔化することで、将来のすべての変更で時間を節約できます。
「行数が少ないほど常により簡潔」	1行の密集した三項演算子は、5行のif/elseより簡潔ではありません。簡潔さは理解速度についてであり、行数についてではありません。
「関連のないこのコードもちょっと簡潔化しよう」	範囲外の簡潔化はdiffをノイズにし、変更しようとしなかったコードで回帰するリスクがあります。フォーカスしてください。
「型があればそれ自体が説明文書」	型は構造を説明していて、意図ではありません。名前の良い関数は、型シグネチャが「何」を説明するより、「なぜ」をより良く説明します。
「この抽象化は後で便利かもしれない」	推測的な抽象化を保持しないでください。今使用されていなければ、それは価値のない複雑さです。削除して、必要なときに再度追加します。
「元の作成者には理由があったはず」	そうかもしれません。git blameをチェック—チェスタートンの柵を適用します。しかし、蓄積した複雑さはしばしば理由がなく、時間的圧力の下での反復の残骸です。
「この機能を追加しながらリファクタリングしよう」	リファクタリングを機能作業から分離してください。混合変更はレビュー、リバート、歴史理解が難しくなります。

赤信号

• テストを合格させるために修正が必要な簡潔化(動作を変更した可能性)
• 元のコードより長く理解しにくい「簡潔化」されたコード
• プロジェクト規約ではなく個人の好みに合わせて物を名前変更する
• コードをより「クリーン」にするためエラーハンドリングを削除する
• 完全に理解していないコードを簡潔化する
• 多くの簡潔化を1つの大きく、レビューが難しいコミットにバッチ処理する
• 依頼されずに現在のタスク範囲外のコードをリファクタリングする

検証

簡潔化パスを完了した後:

• すべての既存テストは修正なしで合格する
• ビルドは新しい警告なしで成功する
• Linter/フォーマッターを合格(スタイル回帰なし)
• 各簡潔化はレビュー可能で段階的な変更である
• diffはクリーン—無関係な変更は混在していない
• 簡潔化されたコードはプロジェクト規約に従う(CLAUDE.md またはそれに相当するものに対して確認)
• エラーハンドリングは削除または弱化されていない
• デッドコードは残されていない(未使用のインポート、到達不可能な分岐)
• チームメートまたはレビューエージェントは変更を改善として承認する