engineering-standards
ソフトウェア開発の基本原則（SOLID、DRY、YAGNI、KISS）の理解と、検出パターンおよびリファクタリング方法を提供します。コード品質のレビュー、アーキテクチャの設計、技術的負債の把握が必要なときに活用できます。
description の原文を見る
Core software engineering principles (SOLID, DRY, YAGNI, KISS) with detection patterns and refactoring guidance. Load when reviewing code quality, planning architecture, or identifying technical debt.
SKILL.md 本文
エンジニアリング標準
高品質なソフトウェアのための基礎原則です。以下の場合に使用してください:
- コードの品質問題をレビューする
- アーキテクチャの変更を計画する
- リファクタリングの機会を特定する
- 技術債を評価する
SOLID原則
単一責任の原則 (SRP)
クラス/モジュールは変更される理由が1つであるべきです。
検出パターン:
- 関連性のないことを行う5個以上のパブリックメソッドを持つクラス
- 50行を超えるメソッド
- クラス名に「And」や「Manager」を含み、関心事が混在している
- 10個以上の無関連なモジュールからインポートするファイル
リファクタリング:
- 各責任ごとにクラスを抽出する
- フォーカスされたモジュールに分割する
- 継承より合成を使用する
開閉原則 (OCP)
拡張に対して開かれ、修正に対して閉じているべきです。
検出パターン:
- 頻繁に追加されるタイプに対するSwitch/case文
- インスタンスタイプをチェックするif/else チェーン
- 新機能を追加するために既存コードを修正する
リファクタリング:
- 動作のバリエーションにはストラテジーパターンを使用する
- 拡張のためのプラグインアーキテクチャ
- 構成可能性のための依存性注入
リスコフ置換原則 (LSP)
サブタイプは基本型の代わりに使用可能でなければなりません。
検出パターン:
- 「実装されていない」という例外をスローするオーバーライド
- 親の動作を無視するサブクラス
- 継承されたメソッドを呼び出す前の型チェック
リファクタリング:
- 継承より合成を優先する
- 真のポリモーフィズムのためにインターフェースを抽出する
- 必須のオーバーライドを持つ抽象基盤を使用する
インターフェース分離の原則 (ISP)
クライアントは使用しないメソッドに依存すべきではありません。
検出パターン:
- 10個以上のメソッドを持つインターフェース
- メソッドを無操作としてスタブする実装クラス
- 関連性のないメソッドグループを含む「太った」インターフェース
リファクタリング:
- ロール固有のインターフェースに分割する
- オプションの動作にはミックスイン/トレイトを使用する
- 複数のフォーカスされたインターフェースを合成する
依存性逆転の原則 (DIP)
具象ではなく抽象に依存してください。
検出パターン:
- 依存性の直接インスタンス化 (
new ConcreteClass()) - ハードコードされたデータベース/API接続
- 本番インスタンスを作成するテストファイル
リファクタリング:
- コンストラクタ注入
- 複雑な生成にはファクトリーパターンを使用する
- インターフェースベースの依存性
DRY (Don't Repeat Yourself)
検出パターン:
- コピー&ペーストされたコードブロック (3回以上の出現)
- わずかな変更がある同様の関数
- 重複した検証ロジック
- 繰り返された構成値
リファクタリング:
- 共有関数/クラスを抽出する
- バリエーションをパラメータ化する
- 構成定数を作成する
- テンプレートメソッドパターンを使用する
許容される重複:
- テストコードの明確性 (DRYより明示的であること)
- 境界間の分離 (マイクロサービス)
- パフォーマンスクリティカルなパス
YAGNI (You Aren't Gonna Need It)
検出パターン:
- 「将来のために」未使用のパラメータ
- 単一実装の抽象クラス
- 使用されないことのない構成オプション
- 推測的な一般化
ガイダンス:
- 現在の要件に対して構築する
- 必要が生じたときにリファクタリングする
- デッドコードをすぐに削除する
- 柔軟性より単純さを優先する
KISS (Keep It Simple, Stupid)
検出パターン:
- 循環複雑度 > 10
- 4階以上のネストされたコールバック/プロミス
- 特定の問題に対する汎用ソリューション
- 単純なタスクのためのフレームワークの過剰使用
リファクタリング:
- 制御フローをフラット化する
- 名前付き関数を抽出する
- 早期リターンを使用する
- つまらないテクノロジーを選択する
コード臭いクイックリファレンス
| 臭い | 症状 | 修正 |
|---|---|---|
| ロングメソッド | 50行以上、複数の関心事 | メソッドを抽出する |
| 大きなクラス | 500行以上、多くの責任 | クラスを抽出する |
| フィーチャーエンビー | メソッドが他のクラスを自身より多く使用する | メソッドを移動する |
| データクランプ | 同じフィールドが一緒に出現する | オブジェクトを抽出する |
| プリミティブ執着 | ドメイン概念に文字列/整数を使用する | 値オブジェクト |
| Switch文 | タイプベースの切り替え | ポリモーフィズム |
| 並列継承 | すべてのサブクラスにパートナーサブクラスが必要 | 階層をマージする |
| 怠け者クラス | クラスの機能が少なすぎる | クラスをインライン化する |
| 投機的一般化 | 未使用の抽象化 | 削除する |
| 一時的フィールド | フィールドが時々しか設定されない | クラスを抽出する |
適用時期
常に適用:
- 本番コードではSRP、DRY
- すべてのコードではKISS
判断を持って適用:
- 拡張ポイントが明確な場合はOCP
- インターフェースが5メソッドを超える場合はISP
- モジュール境界ではDIP
延期:
- YAGNI違反は3回以上パターンが出現するまで延期
詳細なリファクタリング技法については references/refactoring-catalog.md を参照してください。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- ujo78
- ライセンス
- MIT
- 最終更新
- 2026/3/19
Source: https://github.com/ujo78/Minecraft-server-hosting-panel / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理（非同期ジェネレータを含む）、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。