make-native

軽微な機能追加は、そのために設計されていないコードに例外処理を重ねます。あなたの仕事は、機能をネイティブなものとして作り直すことです。

プロセス

1. 機能の差分を読む： git diff <base>...HEAD を実行します。<base> は PR の対象ブランチ（例：gh pr view --json baseRefName -q .baseRefName）または指定されたコミットです。新しい分岐、フラグ、定数、ファイル、テストなど、機能によって追加されたものをすべて列挙します。
2. 元の設計を理解し、それを超えて学ぶ。 変更箇所ごとに、呼び出し元より 1、2 段階深く調べます。型、呼び出し元、履歴（git log -p）を読み、なぜコードがこの形になっているのかを説明できるまで確認します。実行時データ（ログ、エラートラッキング、分析データ、データベースレコードなど）にアクセスできる場合は、実際に発生している経路やケースを確認します。読み取り専用とし、決してコミットしないでください。
3. 機能が最初から仕様に含まれていたかのように再設計する。 「作者が初日からこの機能を知っていたなら、このコードはどのような形になっていただろうか？」と考えます。その形で書き直します。簡素化する機会も活用します。型やユニオンを汎用化し、名前を変更し、構造を組み替え、重複を統合し、新しい形にしたことで不要になるものは削除します。
4. パレートの法則を適用する。 よく使われる 80％のケースを、まず完璧でシンプルにします。その後、残りの 20％にもできる限り対応しますが、80％を犠牲にしてはいけません。エッジケースによって主要な経路が複雑になる場合は、別途処理するか、明確に失敗させます。
5. 新しい設計に合わせてテストを書き直す。 回避策が従来の動作を維持したことだけを検証するテストは削除します。残りのテストは新しい動作に合わせて更新します。既存のテストを変更するのは当然です。
6. 確認する。 最終的なコードを読む人が、どの部分が後から追加されたのか見分けられない状態にします。削除したシンボルを git grep で検索し、残っていないことを確認します。プロジェクトのビルド、リンター、テストを実行します。

解消すべきコードの臭い

• 既存の値を再導出するエイリアス。たとえば、getContentType() がすでに名詞を返すのに、const noun = isVideo ? 'video' : 'image' とするもの。
• 種類ごとにすでに処理を振り分けているコードに、新しい種類の if (newKind) 分岐が散在すること。
• 既存のものを一方のバリエーション向けに複製した新しいファイルやコンポーネント。
• 型がすでに表現している内容と重複する、新しい options トークン、フラグ、ブール値。
• 共通処理の隣に重複して存在するバリデーションやダウンロード経路。
• 「ほかに何も変わっていない」ことだけを目的とするテスト。
• 新しいコストトラッカー、カウンター、ロガー、リトライヘルパー、設定読み込み処理など、すでにある関心事に対する二つ目のシステム。既存のシステムに統合し、不足している部分があれば拡張して、重複を削除します。

ルール

• 機能追加にのみ適用します。バグ修正は最小限にとどめてください。バグ修正のコミットには適用しないでください。
• 新しい抽象化レイヤーを作らないでください。既存のものを組み替えます。
• 本質的に異なる動作は維持します。<video> 要素と <img> 要素の違いは本物です。状態機械の重複はそうではありません。
• 機能追加のコミットとは別にコミットし、リポジトリのコミット規約に従います。Conventional Commits を使用する場合、動作が変わらない再構成には refactor を、再構成によって動作が変わる場合は feat を使います。