コードと待ち時間の計測

比較条件を決める

1. 判断したい費用と測定単位を先に決める。エージェントの感覚で「短い」「軽い」と判定せず、対象範囲、除外対象、コマンド、ツールのバージョン、集計方法をそろえて変更前後を測る。
2. コード量はコード行数、コメント量はコメント行数とコード行数に対する比率、命名は対象の識別子数と命名規則の違反数で数値化する。空行、混在行、生成物の扱いと命名規則を記録し、途中で数え方を変えない。数値だけで品質を断定しない。
3. 基準値、変更後の値、差、判定条件を並べる。既存負債への閾値導入と推移の観測を分け、根拠のない上限を既存コードへ一律に課さない。

実待ち時間と予算

• 並列処理の累積時間と利用者の実待ち時間を分ける。同期イベントの経過時間の中央値・最大値と最長区間を測り、待たない非同期処理を体感時間に加算しない。
• 実運用のランタイム、新規プロセスの初回、再利用後を区別し、起動費用と処理費用を測る。最小入力で固定費を調べ、読み込み順やディレクトリ変更によるフック再実行も組み合わせた状態で測る。
• 頻繁に動く処理には全体・ファイル・単体の目標と退行上限を分けて記録する。手元と CI の時間、並列度、ばらつきを併記し、遅い現状に合わせて上限を緩めない。
• 実行対象の削減、並列化、単体の高速化を実測で比較する。重い検査を別経路へ移す場合も全件を実行する経路を残す。予算で解析を打ち切った場合は、警告なしと区別して通知する。

性能テストの役割を分ける

1. 時間超過は変更箇所を通るか確認し、単独実行で再現を確かめる。並列負荷による超過だけで変更を原因としない。
2. 入力長を変えて時間の比を測る。長さが2倍で時間が4倍なら二乗の増加を疑う。比は入力増加に対する性質、絶対時間は定数倍の遅さを検査する。比も実際の CI で安定性を確認する。CI の perf テストを絶対 ms の上限で落とすと、runner が手元の約 1.8 倍遅いだけで timeout ではない失敗になる（p95 ≤ 100 ms の上限が 87〜112 ms にぶれて落ちた例がある）。4MB と 1MB の入力の p50 の比 ≤ 1.5 と、p95 ≤ 250 ms の退行上限に置き換えると、CI 3 回で p50 が 52〜92 ms とぶれても比は 0.99〜1.00 で通った。runner の速さの差が消える比で判定し、絶対値は退行の上限に回す。
3. 閾値は検出したい最小の退行と正常時のばらつきから決める。全箇所が壊れた場合だけでなく、片方だけが壊れた場合も試し、境界ちょうどの判定を避ける。
4. 実測から入力長・段数の決定的な境界を選べるなら、その境界と出力を unit で検査する。早期失敗する入力では遅さが現れないため、時間検査だけで上限処理の存在を保証しない。
5. 時間自体の検査は負荷の低い直列の性能テストへ分ける。ログや出力など時間に依存しない検査は unit に残す。機能テスト途中のタイムアウトは上限を引数で注入し、テスト時だけ差し替える。プロセス全体の設定変更より局所的な依存の受け渡しを選ぶ。

関数単位の複雑度と通知

• 平均だけでなく最大値、上位関数、関数単位の増分を比較する。分布が偏ると、平均には1関数の悪化がほとんど現れない。
• ファイルと親子の関数名で対応付け、無名関数の重複・改名・新規関数の扱いを明示する。値の降順だけで対応付けると、関数の追加で別の関数同士を比較してしまう。
• 完了時の警告は「前回より増加し、かつ閾値を超えた関数」を対象にする。変化のない既存負債で毎回通知しない。長期の傾向を読む集計とは分ける。
• 作業ツリーを動かさず基準の内容を保存し、未追跡ファイルの扱いと基準が無い・古い場合の判定を決める。計測失敗を改善なしと扱わない。
• フックへの導入前に実行時間と通知先を確認する。利用者向け通知とモデルへの文脈追加は効果が違い、後者は依頼外の修正を誘発しうる。信頼できないリポジトリのファイル名・関数名も入力として扱う。