複数言語の大きなリポジトリを、必要なビルドとテストだけで直す

## 調べて計画してから、最小の変更を作ってテストする すべての変更で、再現可能な次の手順を使います。 1. 依頼内容、関連コード、依存関係のインターフェース、既存テスト、既知の失敗パターンを調査します。 2. 大まかな実装計画を立て、その前提、境界条件、運用上のリスクを検討します。 3. 類似コードを調べ、リポジトリの構成、命名、エラー処理、テストのパターンを把握します。 4. ユーザーが求めた時だけ計画を提示し、それ以外は実装を続けます。 5. 依頼を満たす、整合した最小限の変更を実装します。 6. APIの正確性、明瞭さ、性能、読みやすさ、意図しない範囲拡大の観点から結果を見直します。 7. 整形、対象を絞ったビルド、関連テストを実行し、失敗があれば修正と再検証を繰り返します。 下書きを完了として扱わないでください。実装と、その変更が直接影響する動作のレビューおよび検証が終わった時だけ、変更は準備完了です。 ## 編集の前に、いちばん近い似たコードのやり方に合わせる リポジトリ全体のコントリビューション指針と、変更対象ファイルに適用されるパス固有の指示を読みます。兄弟クラス、隣接パッケージ、類似テスト、関連ワークフローなど、最も近い正常な類例を見つけ、意図的に逸脱する必要がない限り、その既存構造に従います。 信頼できるインターフェースや既存の使用例から、依存APIと境界条件を確認します。新しいテストを作る前に現行テストを探し、別系統のテスト基盤を新設せず、リポジトリ既存のフレームワークへ追加の検証を統合します。 調査範囲は依頼された動作に絞ります。無関係な名前変更、ディレクトリ移動、整形だけの大量差分、アーキテクチャ整理を変更に混ぜないでください。 ## テストの前に、使えるツールと実機を確かめる コマンドを選ぶ前に、実際に利用できるコンパイラ、ランタイム、ビルドツール、コンテナ、アクセラレータ、認証情報を確認します。利用できない能力と製品の不具合を区別してください。必要なデバイスがない、コンテナのランタイムが未対応、ツールチェーンがないという事実だけでは、コードの欠陥は証明されません。 再現性のために必要で、かつ利用可能な場合は、リポジトリ標準のコンテナまたは開発環境を使います。それ以外では、現在の環境で意味のある確認をすべて行い、別のマシンまたはユーザー操作を必要とする残りの最小コマンドを特定します。 実行できなかったテストを合格と主張してはいけません。正確な制約、そのテストなしで完了した検証、残るリスクを報告します。 ## 変更が影響する部分だけをビルドしてテストする 手作業でコマンド列を組み立てるより、リポジトリが用意するプリセットと補助スクリプトを優先します。利用可能なプリセットを確認し、変更対象のコンポーネントと言語レベルに合うものを選び、関連するビルド対象、単体テスト、統合テスト、コンパイラ検査だけに絞ります。 依存関係の情報を使い、共有部分や依存度の高い部分の変更によって影響を受ける下流コンポーネントを対象に含めます。局所的な変更で無関係なパッケージを再ビルドしないでください。全体ビルドと全テストスイートは、横断的な変更、リリースゲート、またはリポジトリの明示的な規則で必要な場合に限ります。 選んだ範囲で十分な理由を記録します。限定的な確認は、その変更との関係が明確な場合にだけ有効です。 ## 言語ごと・アーキテクチャごとに合ったやり方でテストする 言語やパッケージ層ごとに、それぞれ固有のインターフェースに従います。ネイティブライブラリではコンパイラ、言語標準、アーキテクチャの設定が必要になる一方、スクリプト言語のパッケージではランタイムのバージョン、追加依存関係、パッケージ固有のテスト実行口が必要になる場合があります。あるエコシステムの引数を別のエコシステムへ渡さないでください。 アーキテクチャに依存するコードでは、ホストだけで行える確認、コンパイルだけの確認、シミュレータまたは仮想ターゲット、実機を必要とするテストを区別します。既定ですべての種類をコンパイルするのではなく、変更された動作と対応する互換範囲に基づいて、代表的なアーキテクチャを選びます。 共有コンポーネントを変更した時は依存関係グラフを調べ、互換性の後退が表れやすい利用側を検証します。 ## 安い確認から先に回し、遅いビルドを早まって止めない 大規模なビルド、自動生成されたテストマトリクス、実機を使うテストスイートには相当な時間がかかるものと見込みます。現実的なタイムアウトを設定し、対応しているキャッシュを使い、反復中はアーキテクチャと対象を絞り、リスクまたはリリース段階に見合う場合だけ検証範囲を広げます。 時間がかかっていることだけでは、停止している証拠になりません。遅いという理由だけで実行中のビルドやテストを中止せず、具体的な失敗の証拠、明示された運用上の上限、またはユーザーの指示がある場合に限って停止します。 低コストの結果を先に得られるよう、整形と静的検査、対象を絞ったコンパイル、ホストで実行できるテスト、専門環境または実機を必要とするテストの順に検証を進めます。初期の反復で対象を縮小しても、最終的に必要な検証範囲は維持します。 ## 作業中はCIを絞り、マージ前は全部のCIを通す 変更検出とジョブマトリクスを使い、影響を受けるコンポーネントに関連するジョブを実行します。一時的なオーバーライドマトリクスやスキップ制御は、特に基盤変更や依存度の高い領域で、初期の反復コストを減らせますが、常に確認可能で監査できる状態にします。 CIの検証範囲が縮小されている間は、マージ不可として扱います。マージ前にリポジトリが求める完全な設定へ戻し、一時的なオーバーライドやスキップ制御がない状態で実行を成功させます。明示的な指示なしに、別のコントリビューターのオーバーライドを解除したり、その範囲を変更したりしないでください。 ワークフローが設定自体をなくすのではなく空の値を求める場合は、オーバーライド設定を構造的に有効な状態で維持します。必須ジョブの失敗時、または検証範囲の縮小が残っている時に、結果集約が安全側で失敗することを確認します。 ## フォーマッターとリンターを回し、実行しなかった確認も報告する コミット前に、変更したファイルを対象としてリポジトリのフォーマッター、リンター、コミット前チェックを実行します。共通のスタイル指針を先に適用し、その後、対象パスに応じて選ばれる言語、ディレクトリ、テスト固有の規則を適用します。 最終差分を確認し、意図せず含まれたファイル、生成物、命名の不一致、古いコメント、テスト不足がないか調べます。報告する証拠が納品内容と一致するよう、最終編集後に対象を絞った検証をもう一度実行します。 実行した検査、その結果、実行しなかった検査、実行できなかった理由、そこから生じる残余リスクを正確に報告します。必要な実機、ツール、権限、CIの検証範囲が欠けていた場合に、変更が完全に検証済みだと説明してはいけません。