Rust Simplify

Rustコードの「過剰設計」を見つけ、必要十分な設計へ簡素化するための手順と判断基準を提供する。

使いどころ

• 変更対象が「複雑すぎる」「読みにくい」「保守しづらい」と明確に感じられるとき
• 抽象化や分割が目的化しており、要件や将来計画と釣り合っていないとき
• 1回限りの用途に対して汎用化・拡張性が盛られているとき

基本方針

• Less is more / YAGNI を徹底する
• 既存の実装パターンと規約を優先する（このリポジトリのガイドラインが最優先）
• 目的に直結しない抽象化は削る
• 単純化は「挙動・不変条件・性能要件」を守った上で行う

進め方（実務手順）

1. 目的の再確認
   何を改善したいか（可読性、保守性、変更容易性、バグ低減など）を先に言語化する。

2. 過剰設計の兆候を特定
   下のチェックリストを使って、削れる層や不要な抽象化を洗い出す。

3. 簡素化の方針を決める
   置き換えるべき構造（trait、enum、モジュール分割、Builder、Wrapperなど）を具体化する。

4. 変更と整合性の確認
   API互換が不要なら破壊的変更も許容する。必要なら段階的移行にする。

5. テスト・検証
   既存テストを通し、変更目的が達成できたかを確認する。

過剰設計のチェックリスト

• 不要なtrait: 実装が1つしかないのにtraitを切っている
• 過剰なジェネリクス: 型パラメータや境界が必要以上に複雑
• 薄いラッパーの多段化: 1〜2行だけのラッパーが重なっている
• 目的のないモジュール分割: ディレクトリ構成が深いだけで利点がない
• 早すぎる非同期化: 実装・使用箇所が少ないのにasyncが前提
• 拡張性の先取り: まだ使われていない抽象化のための設計
• Arc/Mutexの乱用: 本来は所有権で済むのに共有前提で設計
• Builderの乱用: 必須フィールドが少ないのにBuilderを使っている
• 型の分割過多: 1用途のために細かい型が増えすぎている

よくある簡素化パターン

• trait + 1実装 → 具体型に寄せる
• Enumのバリアント1つだけ → 新規型に統合
• Builder → 直コンストラクタ + 明示的引数
• 深いモジュール分割 → 近接配置で1ファイル化（規約に従う）
• 共有前提 → 所有権/借用ベースの設計に戻す

変更時の注意

• 見た目の短縮だけを目的にしない（理解しやすさが最優先）
• 「将来のための設計」は、具体的な要件がある時だけ行う
• 既存ガイドラインに反する簡素化は行わない