diet

Diet

コードに見合わない重さがないかレビューします。

中心となる問いは次のとおりです。

このコードのうち、現時点で保守コストに見合っていないものは何ですか？

このスキルは、一般的なアーキテクチャやフォルダ構成のレビューではありません。問題に対してコードが過剰に重く感じられる場合の簡素化レビューです。既存の設計に統合するのではなく、仕組みを増やして問題を解決するような、ヘルパー、ラッパー、スキーマフィールド、列、オプション、汎用レイヤー、追加された処理経路が多すぎないかを確認します。フォルダ、ディレクトリ、モジュールの再編成が重さの問題の中心であるか、ユーザーが明示的に求めている場合を除き、話をそちらに逸らさないでください。

コードがLLMやエージェントによって作られたと決めつけないでください。ユーザーが雰囲気で書かれたコードやエージェントが書いた変更について言及した場合も、それはレビューの観点を定める文脈としてのみ扱い、根拠とは見なさないでください。

削除を無理に勧めないでください。明示的で読みやすく、適切な範囲に収まっているコードは、最小限ではなくても、残す価値があることがよくあります。

目標は行数を減らすことではありません。果たすべき責務を減らすことです。つまり、維持すべき概念、状態、分岐、互換性の約束、公開面を減らすことです。

レビューの姿勢

次の原則は、絶対視するのではなく、指針として扱ってください。

• YAGNI：将来の仮定上のケースにだけ必要な仕組みは残さないでください。
• AHA／3回ルール：拙速な抽象化は避け、誤った共通レイヤーを抽出するくらいなら、まず2回重複させてください。
• 誤った抽象化を使うより、重複させるほうが低コストなこともあります。
• 追加より統合を優先する：可能であれば、サイドチャネル、単発のアダプター、並行する処理フローを追加するのではなく、既存の設計の中で問題を解決してください。
• 読みやすさのための明示性を保つ：命名、境界、不変条件を明確にする小さなヘルパー、ラッパー、オブジェクトは、コストに見合う場合があります。

判断のガードレール

• まず、本質的な複雑さと偶発的な複雑さを分けてください。本質的な複雑さは、ドメイン、外部契約、データのライフサイクル、障害モード、セキュリティ、パフォーマンス、ユーザーのワークフローに由来します。偶発的な複雑さは、現在の動作に不要な実装上の仕組みに由来します。
• 削除を勧める前に、何が動かなくなるのか、どのテストや契約を変更する必要があるのか、その動作が公開されているか、永続化されているか、移行されているか、別のサブシステムで使われているかを特定してください。ローカルの根拠から判断できない場合は、その項目をBucket IIに入れてください。
• 互換レイヤー、移行用フィールド、フォールバック、エイリアス、二重読み取りまたは二重書き込みの処理経路は、現在進行中のロールアウト、外部契約、または文書化された移行期間がある場合にのみ、正当なものとして扱ってください。それ以外の場合は、通常Bucket IIの候補です。
• 簡素化は次の順序で優先してください。つまり、簡素化の段階に従います。未使用または仮定上のコードを削除する、単純な受け渡しだけのラッパーをインライン化する、汎用コードを現在の用途に特化させる、追加された処理経路を既存の設計に統合する、フラグやモードを増やすのではなく分岐するケースを分ける、ローカルな簡素化では根本にある重さが残る場合にのみ再設計する、という順です。
• より長い直接的な実装でも、概念、処理の飛び先、設定経路、維持すべき状態が少なくなるなら、より短い抽象化よりも簡素な場合があります。

ワークフロー

1. 実際のコードを基準にレビューします。

• 変更されたファイル、関連するインターフェース、影響を受けるテストやドキュメントを、必要に応じて確認します。
• 次のものを区別します。
  • 現在の動作を実際に担っているコード
  • 主に将来の仮定上の柔軟性のために存在するコード
  • 既存の設計にきれいに統合されず、回避策として追加されたコード

1. 余分な要素がそれぞれ今何をもたらすのかを確認します。

• ヘルパー、ラッパー、フィールド、カラム、オプション、モード、スキーマ項目、抽象化レイヤーごとに、次を確認します。
  • 現在の動作はこれに何を依存していますか？
  • これによって、どの具体的な保守コストが取り除かれますか？
  • 簡素化の段階のどれに該当し、その後にどのようなコード構成が残りますか？

1. 変更をレビュー基準のすべての強いシグナルと照らし合わせ、該当するシグナルをそれぞれ記録します。

2. 基準を高く保ちます。

• 小規模な簡素化で十分な場合に、大規模な再設計を推奨しないでください。
• 指摘をでっち上げないでください。コードはすでに十分に簡潔である、という結論も妥当です。

レビュー基準

コードの簡素化を検討する価値があることを示す強いシグナルとして、次を扱います。

• フィールド、カラム、オプション、設定キー、フックが、主に将来の柔軟性のために存在し、現在の動作ではほとんど使われていない。
• ヘルパー、ラッパー、抽象化が、名前付け、所有権、不変条件、実際の再利用性を改善せずに、処理の段階をひとつ増やしている。
• 汎用的な抽象化、拡張ポイント、戦略用の仕組みに実質的な経路がひとつしかなく、具体的な別の用途もない。
• 抽象化によって隠すはずだった内部の詳細を、呼び出し側が依然として把握する必要がある。
• 共有ヘルパーが、分岐する用途に対応するためにフラグ、型、モード、条件分岐で処理を切り替えるようになっている。
• 汎用的な設計を維持するためだけに、ひとつの概念でマッピングや変換のレイヤーを繰り返し必要としている。
• 修正が既存の設計に統合されず、横に追加されており、その回避策が広がりそうである。
• 現在の処理よりも仮定上の将来の作業を優先した結果、コードの追いやすさが損なわれている。

それ単独では、対応の根拠にならないことが多い弱いシグナルとして、次を扱います。

• コードに多少の重複はあるものの、依然として明確である。
• ヘルパーは単一用途だが、呼び出し箇所や名前を実質的に改善している。
• ラッパーが扱いにくい依存関係や副作用を、より適切な接点の背後に隔離している。
• 小さなオブジェクトが関連データをまとめ、不変条件を把握しやすくしている。
• コードが巧妙さよりも明示性を重視している。
• 共有抽象化を設けるより、多少の重複を許容するほうがコストが低い。

出力

報告には次の構成を使います。

バケット I — 明白／高確度

• あまり議論を必要とせずに簡素化できそうな指摘をここに記載します。
• 簡潔にまとめます。
• 各項目には次を含めます。
  • 過剰に見えるもの
  • 現時点ではコストに見合っていないように思われる理由
  • 最小限の妥当な簡素化の方向性と、その後に残るコード構成
  • 重要な場合に限り、主なトレードオフ

バケット II — 議論する価値あり

• 実際のトレードオフがある場合、制約が不明確な場合、複数の妥当な方向性がある場合、または懸念にはもっともらしさがあるものの根拠が弱い場合は、ここに記載します。確度を誇張しないでください。
• 各項目には次を含めます。
  • 過剰に見えるもの、または後付けに見えるもの
  • 判断を左右する決定事項、または不確かな制約
  • 主な選択肢とトレードオフ

現状維持

• 一見すると重そうでも、現時点で役に立っている設計上の選択を取り上げます。
• 明示性、重複、小さな抽象化が適切な選択である場合は、はっきりそう述べます。

結論

• 次のいずれかで締めくくります。
  • 現状のままで十分に簡潔
  • 対象を絞った簡素化を推奨
  • 推奨する変更には設計上の判断が必要
  • 制約を明確にしたうえで、より広範な再設計を検討する余地あり
• バケット I またはバケット II が空の場合は、その旨を明記します。

スニペットのルール

• コードの根拠を示す必要がある場合は、エディター風の行番号参照よりも、本文に埋め込んだ短いスニペットを優先します。
• 各スニペットの1行目に、コメントとしてソースファイルのパスを記載します。
• スニペットは短く保ちます。通常は、ヘルパーのシグネチャ、スキーマの形、ラッパーのレイヤー、フラグ、モード切り替え、追加された分岐だけで十分です。