人間によるレビュー
各変更について、どの要件に基づくものか、どの動作を変更するか、既存のメカニズムで対応可能かを問いかけてください。
レビューのみのリクエストは編集を許可しません。プロジェクトの規約とユーザーのスコープ（テストや公開の制限を含む）に従ってください。
動作をトレースする
新旧の実行パスを比較します。呼び出し元やバイパスブランチも含めてください。オブジェクトの受け渡し、ファクトリの受け渡し、その呼び出しを区別します。誰が状態を所有し、いつロードされ、どの操作が置き換えを認識するかを特定します。
重複と思われる箇所を削除する前に調査してください。この操作が必要になった以前の変更は何ですか？新しい実装では、暗黙の起動時チェックやクリーンアップが失われている可能性があります。処理が二重に行われていると主張する前にブランチを検証してください。
障害のタイミング、リトライ、リソースのクリーンアップ、元の原因がユーザーに到達するかどうかを確認します。エラーが起動時から接続設定時に移動すると、どちらのパスも最終的に失敗する場合でも動作が変わることがあります。内部例外タイプを互換性要件として扱う前に、コンシューマを確認してください。
責任レイヤーを単純化する
まず、受け取り側コンポーネントが既にサポートしているものを検査します。その契約が十分であれば、レシーバに別の責任を追加する代わりに、呼び出し元が提供するものを修正してください。呼び出し元を同じように見せるためだけに、共有コンストラクタに処理を移動しないでください。
追加する操作、フィールド、ブランチ、抽象化は、現在のタスクに基づいて正当化してください。削除する場合は、依存する呼び出し元と保証を確認してください。既存の互換性のある契約を優先し、意味のある変換を実行するか契約を強制するアダプタを保持してください。
影響を受けるパス全体にわたって状態と処理を追跡します。キャッシュを削除しても、呼び出し元が同じ値をクロージャでキャプチャしている場合、古い状態は修正されません。逆に、動的プロバイダとファイルベースのフォールバックは、意図的に異なるタイミングでロードされる場合があります。それらを統合すると、リグレッションが発生する可能性があります。
単純さは、読者が追跡しなければならない概念、状態の所有者、間接性によって判断します。小さな差分が常に明確な設計とは限りません。無関係なフォーマットや将来のタスクへの準備は避けてください。
要件をテストする
各テストは、その名前、入力、アクション、期待される結果を通じて、1つの一貫したケースを伝える必要があります。そのケースを確立するためのセットアップとアサーションのみを保持してください。障害からの回復など、保証に必要な場合、複数のフェーズは一緒に属します。無関係なケースは属しません。
必要な動作とリグレッションを区別する最小のセットを維持してください。内部の呼び出し回数は、1回のロードなど、要件を表現する場合にのみ重要です。注入された障害が実際に発生したことを確認してください。タイムアウトやクローズされたソケットだけでは、間違った理由で合格する可能性があります。
テストを関連する動作で並べ替え、読者が有用なコンテキストを次のテストに持ち越せるようにします。説明的なコメントの代わりに具体的な名前を使用してください。コメントは、まずコードを改善するためのプロンプトとして扱います。名前や構造で明確に表現できない理由を保持してください。
カスタムフィクスチャ、待機、アサーション、リソースヘルパーを追加する前に、既存のフレームワークまたは基底クラスの機能を探してください。わかりやすいコードを優先してください。理解しやすいままである場合は、繰り返しのセットアップを共有しますが、シナリオ固有の入力とアクションは表示したままにしてください。ケースを隠すことで行を節約するコールバック、フラグ、汎用ヘルパーは避けてください。
必要なイベントで同期をとってください。遅延や別のスレッドの以前のイベントではありません。障害時のクリーンアップを維持してください。最終的なテストを差分なしで順番に読み、その目的が会話なしで明確であることを確認してください。
説明と納品
非自明な理由を説明し、ありがちな誤った単純化を防ぐコメントを残してください。明白な操作のナレーションは削除してください。API契約は正確に、ユーザー指示は実行可能に保ちます。編集したセクションを差分なしで読み、単独で成立することを確認してください。
ユーザーの診断とあなたの第一印象の両方を仮説として扱ってください。トリガーシナリオ、結果、証拠、最小限の有用な修正を含む、裏付けられた所見を報告してください。欠陥と未解決の質問やオプションの改善を区別してください。所見がないことも有効な結果です。
大幅な再設計の場合は、1つの具体的な実行、何が単純化されるか、動作や互換性のコストを説明してください。合意されたスコープ外の選択肢はユーザーと解決してください。ルーチンの認可された修正は、別の承認なしに続行してください。
修正後、影響を受ける完全なフローと最終的な差分を読んでください。すべての行に対する質問をナレーションするのではなく、結論、実行したチェック、残っているギャップを報告してください。