reducing-entropy について
reducing-entropyは、目先の変更量ではなく最終的なコードベースの縮小を重視するソフトウェア開発スキルです。まず参考となる考え方を読み、変更前後のコード量を比較して削除箇所を探します。
主な機能
- 01最終的なコード量で変更を評価
- 02最初に参考となる考え方を読み込む
- 03削除できるコードを確認
- 04柔軟性や分割によるコード増加を指摘
- 05方針が適用されない状況を提示
活用シーン
- 01機能をより少ないコードで実現できるか評価
- 02リファクタリング案から削除機会を探す
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/reducing-entropyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
adding-reference-mindsets.mdreferences/data-over-abstractions.mddesign-is-taking-apart.mdexpensive-to-add-later.mdsimplicity-vs-easy.md詳細
エントロピーの削減
コードは新たなコードを生みます。エントロピーは蓄積していきます。このスキルは、可能な限り最小のコードベースを目指す方向に偏らせるものです。
中心となる問い: 「完成後のコードベースはどのような姿になっているか？」
始める前に
references/ から少なくとも1つのマインドセットを読み込んでください
- 参照ディレクトリ内のファイルを一覧表示する
- フロントマターの説明を読み、どれが当てはまるかを選ぶ
- 少なくとも1つ読み込む
- 読み込んだマインドセットの名前と中核となる原則を述べる
これを終えるまで先に進まないでください。
目標
目標は、書く量を減らすことではなく、最終的なコードベース全体のコード量を減らすことです。
- 200行を削除する代わりに50行を書くのは、正味で得になる
- 2つの関数を書かないために14個の関数を残すのは、正味で損になる
- 「変更を減らす（no churn）」は目標ではありません。目標はコードを減らすことです。
作業量ではなく、最終的な状態を測定してください。
3つの問い
1. このことを解決する最小のコードベースは何か？
「最小の変更」ではなく、最小の結果は何かを考えてください。
- これは14個の関数ではなく、2個の関数で済まないか？
- 0個の関数で済まないか（機能を削除する）？
- これを行うなら、何を削除できるか？
2. 提案された変更によって、コード全体は減るか？
変更前と変更後の行数を数えてください。後の方が多ければ、その変更は却下してください。
- 「より整理されている」が、コードが増える = エントロピーの増加
- 「より柔軟である」が、コードが増える = エントロピーの増加
- 「より明確な責務分離」が、コードが増える = エントロピーの増加
3. 何を削除できるか？
すべての変更は削除の機会です。次のように問いかけてください。
- これによって何が不要になるか？
- 置き換える対象があったからこそ必要だったものは何か？
- 最大でどれだけ削除できるか？
レッドフラグ
- 「既存のものを残す」 - 現状維持バイアスです。問題はコード全体であり、変更の多さではありません。
- 「これは柔軟性を追加する」 - 何のための柔軟性か？ YAGNI（今必要になるまで作るな）。
- 「より良い関心の分離」 - ファイルや関数が増えれば、コードも増えます。分離は無料ではありません。
- 「型安全性」 - 何行に値するのか？ 場合によっては、より少ないコードで済む実行時チェックの方が優れています。
- 「理解しやすい」 - 14個のものは、2個のものより理解しやすいわけではありません。
このスキルが適用されない場合
- コードベースが、その役割に対してすでに最小限である
- 強い規約を持つフレームワークの中で作業している（規約に逆らわない）
- 規制やコンプライアンス上の要件が特定の構造を義務付けている
参照マインドセット
哲学的な背景については references/ を参照してください。
新しいマインドセットを追加するには、adding-reference-mindsets.md を参照してください。
削除を優先してください。最終的な状態を測定してください。
コメント
Markdown 対応