AgentSkillsCN

parse-dont-validate

基于“解析而非验证”原则的代码评审与设计支持。将 validate 模式（检查后丢弃结果）转换为 parse 模式（保留检查结果并以类型强制约束），促进在类型系统中强制执行不变式的设计。当代码评审、新实施或重构时需要改进 validation 函数时使用。适用语言：Rust、Haskell、TypeScript、Scala、Java、Go、Python。触发条件：“想改进验证”、“想用类型保证”、“想纠正 shotgun parsing”、“想用类型防止无效状态”、“想减少 Maybe”等与类型安全相关的请求。

SKILL.md
--- frontmatter
name: parse-dont-validate
description: >-
  「Parse, don't validate」原則に基づくコードレビューと設計支援。validateパターン（チェックして結果を捨てる）
  をparseパターン（チェック結果を型で保持）に変換し、型システムで不変式を強制する設計を促進する。
  コードレビュー、新規実装、リファクタリング時にvalidation関数の改善が必要な場合に使用。
  対象言語: Rust, Haskell, TypeScript, Scala, Java, Go, Python。
  トリガー：「バリデーションを改善して」「型で保証したい」「shotgun parsingを直して」
  「不正な状態を型で防ぎたい」「Maybeを減らしたい」といった型安全性関連リクエストで起動。

Parse, Don't Validate

情報を捨てるvalidationから、情報を保持するparsingへ変換する。

核心原則

チェック結果を捨てずに型で保持する。

アプローチ戻り値情報問題
Validate() / void / bool捨てる再チェック必要、型が保証しない
Parse型付き値保持一度のチェックで済む、型が保証

判断フロー

code
チェック関数を書こうとしている
    ↓
戻り値は何か？
    ├─ () / void / bool → Validateパターン（問題あり）
    └─ 新しい型 → Parseパターン（推奨）

アンチパターン検出

以下のパターンを見つけたら変換を検討：

code
❌ validate*() → ()
❌ check*() → bool
❌ assert*() → ()（表明目的以外）
❌ is*() → bool（分岐後に同じ値を使う場合）
❌ "should never happen" コメント
❌ case None/null の after 正常ケース

変換パターン

1. NonEmpty変換

typescript
// ❌ Validate: 情報を捨てる
function validateNonEmpty(list: string[]): void {
  if (list.length === 0) throw new Error("list cannot be empty");
}

// ✅ Parse: 情報を保持する
type NonEmptyArray<T> = [T, ...T[]];
function parseNonEmpty<T>(list: T[]): NonEmptyArray<T> {
  if (list.length === 0) throw new Error("list cannot be empty");
  return list as NonEmptyArray<T>;
}

2. 重複キー検出

typescript
// ❌ Validate: チェックして捨てる
function checkNoDuplicateKeys(pairs: [string, unknown][]): void {
  const seen = new Set<string>();
  for (const [key] of pairs) {
    if (seen.has(key)) throw new Error(`duplicate key: ${key}`);
    seen.add(key);
  }
}

// ✅ Parse: Mapに変換して保持
function parseToMap(pairs: [string, unknown][]): Map<string, unknown> {
  const result = new Map<string, unknown>();
  for (const [key, value] of pairs) {
    if (result.has(key)) throw new Error(`duplicate key: ${key}`);
    result.set(key, value);
  }
  return result;
}

3. Smart Constructor

rust
// ❌ 外部から直接構築可能
pub struct Email(String);

// ✅ Parse: Smart constructorで検証済みを保証
mod email {
    pub struct Email(String);  // private field

    impl Email {
        pub fn parse(s: &str) -> Result<Self, ParseError> {
            if s.contains('@') && s.len() > 3 {
                Ok(Email(s.to_string()))
            } else {
                Err(ParseError::InvalidEmail)
            }
        }

        pub fn as_str(&self) -> &str { &self.0 }
    }
}

Shotgun Parsing

避けるべき: 入力検証がコード全体に散らばるパターン。

code
❌ 処理開始 → 部分処理 → 検証失敗 → ロールバック困難
✅ 境界で完全Parse → 処理は型を信頼 → 安全

適用指針

推奨

  • •システム境界での入力処理（JSON, CLI引数, DB値）
  • •複雑な不変式を持つドメインモデル
  • •Maybe/Optionが頻出する箇所
  • •"should never happen" コメントがある箇所

過剰適用を避ける

  • •単一のerror "impossible"だけなら改修コスト大
  • •既存APIとの互換性が必要な場合
  • •パフォーマンスクリティカルなホットパス

レビュー観点

コードレビュー時の確認ポイント：

  1. •戻り値チェック: void/()を返す検証関数はないか
  2. •型の精度: より精密な型で表現できないか
  3. •境界の明確さ: 入力パースはシステム境界で完結しているか
  4. •shotgun: 検証ロジックがコード全体に散らばっていないか

詳細ガイドライン

言語別の実装パターン、型設計の詳細は references/patterns.md を参照。

関連スキル（併読推奨）

このスキルを使用する際は、以下のスキルも併せて参照すること：

  • •domain-primitives-and-always-valid: スマートコンストラクタによるドメインプリミティブの設計
  • •when-to-wrap-primitives: プリミティブ型をラップすべきかの判断基準
  • •domain-building-blocks: 値オブジェクトの設計（parseパターンの適用先）