reducing-entropy

エントロピーの削減

コードは新たなコードを生みます。エントロピーは蓄積していきます。このスキルは、可能な限り最小のコードベースを目指す方向に偏らせるものです。

中心となる問い: 「完成後のコードベースはどのような姿になっているか？」

始める前に

references/ から少なくとも1つのマインドセットを読み込んでください

1. 参照ディレクトリ内のファイルを一覧表示する
2. フロントマターの説明を読み、どれが当てはまるかを選ぶ
3. 少なくとも1つ読み込む
4. 読み込んだマインドセットの名前と中核となる原則を述べる

これを終えるまで先に進まないでください。

目標

目標は、書く量を減らすことではなく、最終的なコードベース全体のコード量を減らすことです。

• 200行を削除する代わりに50行を書くのは、正味で得になる
• 2つの関数を書かないために14個の関数を残すのは、正味で損になる
• 「変更を減らす（no churn）」は目標ではありません。目標はコードを減らすことです。

作業量ではなく、最終的な状態を測定してください。

3つの問い

1. このことを解決する最小のコードベースは何か？

「最小の変更」ではなく、最小の結果は何かを考えてください。

• これは14個の関数ではなく、2個の関数で済まないか？
• 0個の関数で済まないか（機能を削除する）？
• これを行うなら、何を削除できるか？

2. 提案された変更によって、コード全体は減るか？

変更前と変更後の行数を数えてください。後の方が多ければ、その変更は却下してください。

• 「より整理されている」が、コードが増える = エントロピーの増加
• 「より柔軟である」が、コードが増える = エントロピーの増加
• 「より明確な責務分離」が、コードが増える = エントロピーの増加

3. 何を削除できるか？

すべての変更は削除の機会です。次のように問いかけてください。

• これによって何が不要になるか？
• 置き換える対象があったからこそ必要だったものは何か？
• 最大でどれだけ削除できるか？

レッドフラグ

• 「既存のものを残す」 - 現状維持バイアスです。問題はコード全体であり、変更の多さではありません。
• 「これは柔軟性を追加する」 - 何のための柔軟性か？ YAGNI（今必要になるまで作るな）。
• 「より良い関心の分離」 - ファイルや関数が増えれば、コードも増えます。分離は無料ではありません。
• 「型安全性」 - 何行に値するのか？ 場合によっては、より少ないコードで済む実行時チェックの方が優れています。
• 「理解しやすい」 - 14個のものは、2個のものより理解しやすいわけではありません。

このスキルが適用されない場合

• コードベースが、その役割に対してすでに最小限である
• 強い規約を持つフレームワークの中で作業している（規約に逆らわない）
• 規制やコンプライアンス上の要件が特定の構造を義務付けている

参照マインドセット

哲学的な背景については references/ を参照してください。

新しいマインドセットを追加するには、adding-reference-mindsets.md を参照してください。

---

削除を優先してください。最終的な状態を測定してください。