ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: コードを書いたり変更したりするときに使用します。タスクを完了と呼ぶ前に、変更がエクスポートまたはインポート可能な名前を追加したり、モジュール、クラス、コンポーネント、ヘルパー、フック、サービス、ラッパーを作成したり、繰り返しのコードを集約したりする場合に使います。深いモジュールを構築するための著者時チェックリスト：境界が隠す決定に名前を付け、深さと不変条件のテストに合格し、問題を移動させるのではなく修正し、サイズだけで分割しないこと、そして短い設計ノートで締めくくること。ousterhout-quality-programのコンパクトな補完であり、そちらは完全なレビューの視点を維持します。
---

# Build it deep (Ousterhout, author-time)

あなたはコードを書いているのであって、レビューしているのではありません。タスクを完了と呼ぶ前に、自分の変更でこれを実行してください。

## 1. ゲート

変更がエクスポート/インポート可能な名前を追加したり、モジュール、クラス、コンポーネント、ヘルパー、フック、サービス、ラッパーを作成したり、繰り返しのコードを集約したりしていますか？もし違うなら、このスキルはスキップしてください。リネーム、コードモッド、設定/データの編集、一行修正は対象外です。

## 2. 境界を書く前に

- このリポジトリがすでにこの形の問題をどのように解決しているかを見つけ、それに従ってください。そうしない理由を明確に述べられない限り従うべきです。依存先の現在のドキュメントと型を読みましょう。記憶から呼び出すAPIは主張であって情報源ではありません。
- まずインターフェースのコメントを書きます：何を約束し、何を隠すのか。隠された決定（フォーマット、ポリシー、ルール、スキーマの選択など）を名前にできないなら、その境界は存在すべきではありません。インラインにしてください。
- ドメイン言語で名前を付けます。唯一正直な名前が`utils`、`helpers`、`manager`なら、その切り口は間違っています。

## 3. 2つのテスト

- **深さ。** インターフェースは公開する以上にかなり多くを隠す必要があります。引数をそのまま渡すだけのラッパーはコストだけで利益がありません。削除してください。
- **不変条件。** 共有コードは共有ルールを守るときだけ抽出します。証拠は共変化です：コピーは歴史的に一緒に修正または変更されています。独立して変わる類似コードは複製のままにします。

## 4. 修正は問題を移動させるのではなく取り除くべき

- 6つのキャストを1つのジェネリックキャストヘルパーにまとめても、依然として6つのキャストです。キャストでごまかしていた型付きマッパーを書いてください。
- 呼び出し側が本当にあなたの知らない何かを知っていない限り、決定を呼び出し側に押し付けるパラメータやフラグを追加しないでください。難しいケースは内部で吸収してください。
- エラーケースが起こりえない意味論を優先し、すべての呼び出し側に処理させるのは避けてください。
- 重要なドメインの複雑さを別ファイルに移すことは簡素化ではありません。

## 5. 「これを整理しろ」や「このファイルは大きすぎる」という圧力の下で

サイズだけで分割してはいけません。1つの決定を隠す400行のモジュールは、同じ結合を漏らす4つの100行モジュールより優れています。分割ごとにどの決定を隠しているかを問うてください。なければ分割しないでください。

## 6. 安全性

既存コード：深める前に現在の振る舞いをテストで固定してください。新規コード：意図した振る舞いを定義するテストを書いてください。

## 7. レポート

ゲートが発動した場合、最終メッセージの最後に2～4行の設計ノートを付けてください：追加した各境界と隠した決定、意図的に残した重複とその理由、受け入れた浅いものとその理由。

議論が必要な判断や完全なレビューの場合は、`ousterhout-quality-program`を読み込んでください。

タグ