simplify

シンプルにする

必要な動作を完全に満たす、明快で最小の実装を作成します。行数ではなく、概念と可動部分を最小限に抑えます。

進め方

• コードを追加する前に、要件を満たす最小の変更を決めます。新しい概念は、それを追加する価値がある場合に限ります。
• 実装中は、動作を把握しながら各所で優先事項を適用します。学習を早めるために役立つ場合は、明らかに一時的な計測や足場を許容します。
• 収束したら、論理的な動作のまとまりが検証に合格した時点で、そのまとまりを簡素化し、置き換えられた試みや足場を削除して、対象を絞った検証を再実行します。
• ブランチ全体の監査が明示的に依頼された場合は、意図したベースと比較します。それ以外の場合は依頼された変更だけを確認し、小さなクリーンアップをブランチ全体の監査に広げないでください。

ワークフロー

1. 必要な動作、不変条件、制約、対象外事項を特定します。
2. 関連する差分を確認し、論理的な概念ごとに分けます。ブランチ全体の最終監査では、マージベースとの差分全体を確認し、必要に応じて履歴から置き換えられた試みを調べます。
3. 何かを追加する前に、既存の責務の所在、信頼できる情報源、一般的な経路、判断箇所、近くのコードスタイルを確認します。
4. 必要な概念が最も少なく、実行時の作業も最小限となる設計を選びます。
5. 変更を依頼された場合は、既存の仕組みが適していればそれを再利用し、直接実装します。
6. リスクに見合ったチェックで動作を検証します。
7. 最終コード、テスト、命名、コメント、ドキュメント、設定、関連する履歴を見直し、複雑さに見合う価値のないものを確認します。

簡素化の優先事項

• リポジトリの既存のスタイルやパターンに合わせます。命名、ファイル配置、エラー処理、テストスタイル、すでに使用しているライブラリに従います。既存のパターンが適用できる箇所で、新しいパターンを導入しないでください。
• 新しい抽象化を追加するより、削除、再利用、直接変更を優先します。
• 信頼できる情報源は一つに保ちます。状態の二重管理、重複するガード、重複したレジストリ、補償的な仕組みを避けます。
• リポジトリに慣例がない場合は、早期リターンの連鎖や空の分岐より、単純で肯定形の制御フローを優先します。
• ホットパスでは、メモリ割り当て、コールバックの再生成、サブスクリプション、レンダー、パス、I/O、ネイティブ処理を最小限に抑えます。
• 文章では繰り返しを削り、単独で理解できる最短の言い回しや例を使います。

過剰設計チェックリスト

必要な動作、不変条件、有用な明快さ、実測されたパフォーマンス上の必要性、既存のリポジトリの慣例に役立たないものは、次の項目を削除します。

• インライン化できる、一度しか使わないヘルパー。
• 型や呼び出し元ですでに排除されている状態に対する、防御的な null チェックや型チェック。
• 現在の呼び出し元で必要とされていない、設定フラグ、オプション、パラメーター。
• 呼び出しを仲介するだけのラッパー型やクラス。
• 既存の責務の所在で対応できる、新しいファイル、モジュール、抽象化。
• タスクで必要とされていない、フォールバック、互換性、移行のための経路。
• エラーを握りつぶす、または暗黙にフォールバックする try/catch ブロック。
• まだ何も利用していない拡張ポイントやケースなど、推測に基づく汎用性。

行単位の見直し

• 追加したブロックは、差分だけでなく、その前後にある既存コードとあわせてすべて読みます。
• 周囲のコードですでに行われている文、return、分岐を重複させる新しいコードを洗い出します。
• 既存のコードに並行する経路を追加するより、ガードで囲む、ラップする、実行をスキップするほうが小さく済むケースを洗い出します。
• 到達不能になった、または冗長になった既存の行を洗い出します。
• それぞれのケースに対して、より小さな書き換えを適用するか、その内容を報告します。差分が簡潔で妥当だというだけの評価では不十分です。
• 例：if (sortsAfterTail) { queue.push(task); return; } という高速経路が、スキャンループの前にあり、そのループの末尾ですでに queue.push(task) を実行していると、push が重複します。両方の経路を一つの末尾の push で処理できるよう、ループを if (!sortsAfterTail) で囲みます。

既存の作業

動作しているコードを簡素化する前に、テストが通るベースラインを確立してください。疑わしい概念は一度に一つずつ検証し、関連する検証を再実行してください。動作や有意義なカバレッジが損なわれた場合は、その変更を元に戻してください。どの変更が因果的に必要なのかを確立する前に、積み重なった複数の修正試行を再構成してはいけません。

重複している、または効果のないリグレッションカバレッジが疑われる場合は、主張されている不変条件を意図的に破り、残りのテストが失敗することを確認してください。テストが通ることだけでは、すべてのテストや実装上の概念が必要であるとは証明できません。

許可なくブランチの履歴を書き換えてはいけません。

パフォーマンスの変更

削減する一般的な処理を具体的に挙げてください。たとえば、メモリ割り当て、スキャン、マウント、レンダー、サブスクリプション、I/O、ネイティブ呼び出しなどです。制御フローの根拠とリグレッションテストがあれば、構造上使用されていない処理を削除できます。最適化によってセマンティクスが変わる場合や、トレードオフが生じる場合は、ベンチマーク、プロファイル、または再現性のある検証を必須としてください。理論上の改善のために複雑さを増やしてはいけません。

ガードレール

• 正確性、必須の動作、型安全性、個別のリグレッションカバレッジ、わかりやすさを維持してください。
• 行数を減らすだけのために、明快なコードを圧縮したコードや技巧的なコードに置き換えてはいけません。
• 範囲を限定した、動作を変えない改善は直接行ってください。依頼された変更を超える単純化が公開 API を変更したり、新しい概念を追加したりする場合は、代わりに説明して提案してください。
• 関係のない変更やユーザーが作成した変更には手を加えないでください。

残るすべての概念が、要件、不変条件、わかりやすさ、既存のリポジトリ規約、または測定されたパフォーマンス上の必要性を支える時点で終了してください。報告するのは、重要な簡素化、検証結果、未解決の改善機会のみです。