# 既存システム知識

## 既存システムの契約

既存システムでは、明示的なAPIだけでなく、利用者や開発者が観測している値や構造も契約として機能する。コード上は小さな変更でも、運用中の画面、テスト、レビュー、保守手順に影響する。

| 基準 | 判定 |
|------|------|
| 利用者が目にする文言や状態が変わる | 契約変更 |
| テストが検証している値が変わる | 契約変更 |
| hook や component の呼び出し方が変わる | 契約変更 |
| ファイル配置や型名だけが変わる | 保守契約の変更になりうる |
| 実装内部の閉じた重複を削る | 影響範囲が閉じていれば内部変更 |

## 差分分類

既存システムの変更は、要求との因果関係で分類する。変更対象ファイルに含まれているかどうかではなく、その変更が要求達成に必要かで判断する。

| 分類 | 判断基準 |
|------|----------|
| 必須変更 | 要求を満たすために直接必要 |
| 関連変更 | 必須変更を配線、検証、整合させるために必要 |
| 不要変更 | なくても要求が満たせる |
| 危険な不要変更 | なくても要求が満たせ、既存契約も変える |

### 関連変更の境界

関連変更は必須変更との接続理由を説明できる必要がある。近い場所、同じファイル、同じ責務というだけでは関連変更にならない。

| 例 | 分類 |
|----|------|
| 新しい引数を追加した関数の呼び出し元更新 | 関連変更 |
| 永続化先を変えたため古いstoreを削除 | 関連変更 |
| 触ったcomponentのProps型名を好みで変更 | 不要変更 |
| ついでにhookの戻り値をprops objectへ変更 | 危険な不要変更 |

## 一般品質基準との衝突

保守作業では、一般的な設計改善やフレームワーク作法が常に優先されるわけではない。既存の構造が理想的でなくても、今回の要求と無関係なら変更しない方が回帰リスクは低い。

| 状況 | 判断 |
|------|------|
| コンポーネント分割した方がきれいだが、今回の修正に不要 | 変更しない |
| Props 型名や配置を一般作法へ寄せたいだけ | 変更しない |
| 既存構造のままだと要求を満たせない | 最小範囲で変更する |
| 既存構造が不具合原因そのもの | 理由と影響範囲を明記して変更する |

## コメントとテストの意味

コメントやテストは、過去の制約や意図を保存していることがある。説明に見えるコメントでも、算出根拠、プラットフォーム制約、既知の不具合回避を示す場合は契約に近い役割を持つ。

| 対象 | 扱い |
|------|------|
| 算出根拠コメント | 保持する |
| 制約や回避策のコメント | 保持する |
| コードと矛盾したコメント | 修正する |
| 関数名の言い換えだけのコメント | 削除を検討できる |
| 既存テストの期待値 | 既存契約として扱う |

## 保守変更のリスク

保守変更では、新しいコードの良さより既存挙動の保持が重要になる。設計として良い変更でも、要求外ならレビュー負荷と回帰リスクを増やす。

| 変更 | リスク |
|------|--------|
| 改名 | grep、履歴追跡、レビュー範囲が増える |
| ファイル移動 | 所有境界、import、履歴追跡が変わる |
| UI契約変更 | 利用者体験、支援技術、テストが変わる |
| テスト緩和 | 回帰検出力が落ちる |
| 追加抽象化 | 将来ではなく現在の理解コストが増える |
