reference-hunt

リファレンスの調査

複雑すぎたり、暗黙的すぎたりして要件として書き起こせない場合でも、どこかにある動作するコードにすでに反映されていることがあります。最適なリファレンスはスクリーンショットや説明ではなく、ソースコードです。仕様書として読み、構文ではなく意味を再実装してください。

手順

1. リファレンスを入手します。リポジトリのパス、ベンダー提供のフォルダー、ライブラリ名、または基となるコードを読めるサイトなどが該当します。誤った側面を模倣しないよう、そこから具体的に何を抽出するのか、振る舞い、構造、ビジュアルシステム、API の形などを確認します。
2. コードを書く前にリファレンスを読み、意味の要約を作成します。
   • 実装されている振る舞いと保証（タイミング、順序、エラー処理、エッジケース）。
   • 意図的に見える決定と、偶発的に見える決定。
   • 対象の言語やスタックに移せない点と、その代替案。
3. 意味の要約をユーザーに確認してもらいます。この段階で、誤解を低コストで見つけられます。
4. 対象のスタックで再実装します。同じ意味を保ちながら、ネイティブな慣用表現を使ってください。1 行ずつ置き換えたり、ライセンスで許可されていないリファレンスのコードをそのままコピーしたりしないでください。ライセンスが不明な場合は、その旨を記載します。
5. 最後に、要約に挙げた各振る舞いと、新しい実装でそれをどのように実現しているかを示します。また、意図的に異なる点があれば、その理由も説明します。

ガードレール

• リファレンスが定義するのは「何をするか」です。「どのようにするか」は対象コードベースの規約に従います。
• リファレンスにバグや一貫性のない挙動が見つかった場合は、それを忠実に再現するのではなく、問題として明らかにします。
• ライセンスを尊重してください。意味の抽出は問題ありませんが、互換性のないコードのコピーは許可されません。