simplify-code-solution

コードソリューションの簡素化

提案されたソリューションでも既存のコードでも、コードに関する問題を解決する、最もシンプルで本番環境に適した設計を見つけます。シンプルとは、実際の要件をすべて満たしたうえで、理解や変更がしやすいことです。ファイル、関数、行数が少ないだけでは、ソリューションがシンプルになったとはいえません。

1. モードを選ぶ

• 提案: 「もっとシンプルにできますか？」のような質問や、提案のレビューに使います。ファイルは編集しません。提案の修正を求められた場合は、説明対象のコードではなく、提案を変更します。
• 実装: コードの簡素化やリファクタリング、または提案の適用をユーザーが求めている場合に使います。変更を加え、あらためて承認を求めずに検証します。

ユーザーが変更を求めていない限り、提案モードを維持します。設計を気に入っていることは、実装の依頼ではありません。解決策やその範囲が変わるような判断材料が不足している場合に限り、質問してください。

2. コードに必要なことを把握する

現在のパスにあるコード、その呼び出し元、テスト、ローカルのパターンを読み、要件とリスクが明確になった時点で調査を終えます。次に、以下を切り分けます。

• 要件: 呼び出し元が依存する動作や契約、成功基準。
• 前提とあれば望ましいもの: 削除できる可能性があるもの。
• 維持すべき複雑さ: 実際のドメインルール、永続性、復旧、運用上の保証を表すコード。永続キュー、明示的な状態、ドメイン上の区別は過剰に見えても、必要な場合があります。

仕組みの削除を提案する前に、その利用者、運用や障害対応における役割、置き換え方法を把握してください。

3. よりシンプルな形を見つける

以下を検討してください。

• 無関係な責務を負わせることなく、既存のパス、ヘルパー、型、コンポーネント、APIに動作を取り込めないか
• 言語、フレームワーク、既存の依存関係がすでに提供している機能を、コードが重複して実装していないか
• 実質的に1つのバリエーションしかない汎用コード、拡張ポイント、設定
• 局所的なバグに対する書き換え、単純な状態に対するステートマシン、1つの呼び出し元のためのフレームワーク、憶測に基づく移行、新しい依存関係、内部的な利便性のための広範なAPI変更
• 呼び出しをたどる手間しか増やさないラッパー。まず呼び出し元を読み、呼び出し元が自ら担うことになるルール、クリーンアップ、互換性対応を処理するラッパーは維持してください。
• 自然な責務の置き場所から離れているロジックや、独立したワークフローまで抱えている責務の持ち主

呼び出し元が知るべきことを減らし、実際の複雑さを隠すなら、呼び出し元が1つでも専用モジュールを設ける価値があります。初期の規模ではなく、ライフサイクル全体のコストを比較し、複雑さ、リスク、手作業を後工程に押しつける簡素化は避けてください。

インターフェースを置き換える場合は、テストを含め、すべての利用者を見つけてください。同じ動作を確認しながら、テストを置き換え先に移します。テストだけのために古いAPIを残してはいけません。他の呼び出し元や段階的な移行に必要な間は維持し、一時的なアダプターをいつ削除できるかを明記してください。

簡素化できる箇所を見つけたら、依頼された範囲の残りにも同じ問題がないか確認し、該当箇所を含めてください。範囲外の事例は、別途報告してください。

4. 実装する

実装モードでは、リファクタリングの前に関連するテストを実行し、変更後も同じ意味のあるケースを維持します。期待結果を変更してよいのは、契約変更が承認されている場合、またはテストの誤りが実証されている場合だけです。失敗を隠すような方法で、フィクスチャ、モック、テストの選択を変更してはいけません。動作修正を含む作業では、利用可能な場合は tdd スキルを使ってください。そうでない場合は、コード修正前に回帰テストが失敗することを確認してください。

変更と検証を最後まで進め、提案の段階で止めないでください。ブロッカーにより作業を進められない場合は、有効な失敗テストをそのまま残し、未確定の判断事項と残作業を報告してください。

5. 報告する

提案の場合は、次の形式を使い、記載することがない行は省略してください。

**Requirements:** what the code must keep doing.

**Complexity to keep:** what stays, and why.

**Assumptions to drop:** what the current design assumes without a requirement.

**Simpler path:** the concrete change, with locations.

**Tradeoffs:** what gets worse or riskier.

**Validation:** how to confirm behavior is preserved.

実装の場合は、変更内容、シンプルになった理由、実施した確認とその結果、制約事項を報告してください。