クリーンコード原則

基本的なソフトウェア設計原則、SOLID、デザインパターン、およびクリーンコード実践。保守性が高く、スケーラブルなソフトウェアを書くための言語に依存しないガイドライン。

適用時期

以下の場合にこれらのガイドラインを参照してください：

• 新機能またはシステムを設計する場合
• コードアーキテクチャをレビューする場合
• 既存コードをリファクタリングする場合
• 設計決定について議論する場合
• コード品質を向上させる場合

ルールカテゴリーを優先度別に分類

優先度	カテゴリー	影響度	プレフィックス
1	SOLID原則	CRITICAL	solid-
2	コア原則	CRITICAL	core-
3	デザインパターン	HIGH	pattern-
4	コード組織	HIGH	org-
5	命名と可読性	MEDIUM	name-
6	関数とメソッド	MEDIUM	func-
7	コメントとドキュメント	LOW	doc-

クイックリファレンス

1. SOLID原則（CRITICAL）

• solid-srp - 単一責任の原則
• solid-ocp - 開放閉鎖の原則
• solid-lsp - リスコフの置換原則
• solid-isp - インターフェース分離の原則
• solid-dip - 依存性逆転の原則

2. コア原則（CRITICAL）

• core-dry - 繰り返さない（Don't Repeat Yourself）
• core-kiss - シンプルを心がける（Keep It Simple, Stupid）
• core-yagni - 必要になるまで作らない（You Aren't Gonna Need It）
• core-separation-of-concerns - 責任を分離する
• core-composition-over-inheritance - コンポジションを優先
• core-law-of-demeter - 最小知識の原則
• core-fail-fast - エラーを早期に検出・報告
• core-encapsulation - 実装詳細を隠蔽

3. デザインパターン（HIGH）

• pattern-factory - オブジェクト生成用ファクトリパターン
• pattern-strategy - アルゴリズム用ストラテジパターン
• pattern-repository - データアクセス用リポジトリパターン
• pattern-decorator - 動作拡張用デコレータパターン
• pattern-observer - イベント処理用オブザーバーパターン
• pattern-adapter - インターフェース変換用アダプターパターン
• pattern-facade - インターフェース簡潔化用ファサードパターン
• pattern-dependency-injection - 疎結合のための依存性注入

4. コード組織（HIGH）— 計画中

• org-feature-folders - レイヤーではなく機能で構成
• org-module-boundaries - 明確なモジュール境界
• org-layered-architecture - 適切なレイヤー分離
• org-package-cohesion - 関連コードを一緒に
• org-circular-dependencies - 循環インポートを回避

5. 命名と可読性（MEDIUM）— 計画中

• name-meaningful - 意図を明確にした命名
• name-consistent - 一貫した命名規則
• name-searchable - マジックナンバー/文字列を回避
• name-avoid-encodings - ハンガリアン記法なし
• name-domain-language - ドメイン用語を使用

6. 関数とメソッド（MEDIUM）— 計画中

• func-small - 関数は小さく保つ
• func-single-purpose - 1つのことだけを実行
• func-few-arguments - パラメータ数を制限
• func-no-side-effects - 副作用を最小化
• func-command-query - コマンドとクエリを分離

7. コメントとドキュメント（LOW）— 計画中

• doc-self-documenting - コードが自分自身を説明する
• doc-why-not-what - 何でなく、なぜを説明
• doc-avoid-noise - 冗長なコメントなし
• doc-api-docs - パブリックAPIをドキュメント化

基本的なガイドライン

詳細な例と説明についてはルールファイルを参照してください：

• core-dry.md - DRY原則
• pattern-repository.md - リポジトリパターン

SOLID原則（概要）

原則	定義
Single Responsibility	クラスは変更の理由が1つだけ
Open/Closed	拡張に開き、変更に閉じている
Liskov Substitution	サブタイプは基本型の代替可能
Interface Segregation	クライアントに不要なインターフェースを強制しない
Dependency Inversion	具体的な実装でなく、抽象に依存する

コア原則（概要）

原則	定義
DRY	繰り返さない - 唯一の情報源
KISS	シンプルに - 過度な設計を避ける
YAGNI	必要になるまで作らない - 必要なものだけを構築

クイック例

// 単一責任の原則 - 1つのクラス、1つのジョブ
class UserService {
  constructor(
    private validator: UserValidator,
    private repository: UserRepository,
  ) {}

  createUser(data) {
    this.validator.validate(data);
    return this.repository.create(data);
  }
}

// 依存性逆転の原則 - 抽象に依存
interface Repository<T> {
  find(id: string): Promise<T | null>;
  save(entity: T): Promise<T>;
}

class OrderService {
  constructor(private repository: Repository<Order>) {}
}

// DRY - 唯一の情報源
const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
const isValidEmail = (email: string) => EMAIL_REGEX.test(email);

// マジックナンバーではなく意味のある名前
const MINIMUM_AGE = 18;
if (user.age >= MINIMUM_AGE) { }

出力形式

コードを監査する場合、以下の形式で結果を出力してください：

file:line - [principle] Description of issue

例：

src/services/UserService.ts:15 - [solid-srp] Class handles validation, persistence, and notifications
src/utils/helpers.ts:42 - [core-dry] Email validation duplicated from validators/email.ts
src/models/Order.ts:28 - [name-meaningful] Variable 'x' should describe its purpose

使用方法

詳細な説明についてはルールファイルを参照してください：

rules/solid-srp-class.md
rules/core-dry.md
rules/pattern-repository.md

参考資料

このスキルは確立されたソフトウェアエンジニアリング原則に基づいています：

コア書籍

• Clean Code by Robert C. Martin - クリーンコード実践の基礎
• Design Patterns by Gang of Four - デザインパターンの古典的カタログ
• Refactoring by Martin Fowler - コード構造の改善
• The Pragmatic Programmer by Hunt & Thomas - 実践的な知恵

オンラインリソース

• Refactoring Guru - デザインパターンとコード臭
• Martin Fowler's Refactoring Catalog - 包括的なリファクタリング技法
• Uncle Bob's Clean Coder Blog - ソフトウェア職人気質の記事

パターンカタログ

• Refactoring Guru - Design Patterns
• Martin Fowler - Enterprise Patterns

メタデータ

バージョン： 1.0.2 ステータス： アクティブ カバレッジ： 3つの実装カテゴリー（SOLID、コア原則、デザインパターン）にわたる23ルール、4つが計画中 最終更新： 2026-03-07

ルール統計

• SOLID原則：10ルール
• コア原則：12ルール
• デザインパターン：1ルール