# Rust Simplify

> Rustコードの過剰設計を解消してシンプルにする依頼で使う。抽象化の過多、不要な分割、過剰な汎用化を減らし、読みやすさと保守性を優先する。

- Skill: `majiayu000/rust-simplify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/rust-simplify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/rust-simplify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/rust-simplify

---


# 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ファイル化（規約に従う）  
- 共有前提 → 所有権/借用ベースの設計に戻す  

## 変更時の注意

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