The Standard Core

The Standard のコア

このスキルについて

このスキルは、他のすべての Standard スキルを統括するレイヤーです。 設計、実装、テスト、レビュー、計画に関するすべての判断を導く理論、運用モデル、コアバリューを定義します。

The Standard はテクノロジーに依存しません。 言語、フレームワーク、ランタイム、ホスティングモデルにかかわらず適用してください。 C# と .NET の例は理論そのものではなく、理論を具体化したものとしてのみ使用してください。

明示的な対象範囲

このスキルは、The Standard の基礎となる内容を明示的に扱います。

• 0. はじめに
• 0.0 理論
  • 0.0.0 はじめに
  • 0.0.1 答えを見つける
  • 0.0.2 三位一体
  • 0.0.2.0 目的
  • 0.0.2.1 依存関係
  • 0.0.2.2 公開
  • 0.0.3 すべてはつながっている
  • 0.0.4 フラクタルパターン
  • 0.0.5 システム設計とアーキテクチャ
  • 0.0.6 まとめ
• 0.1 目的設定、モデリング、シミュレーション
  • 0.1.0 はじめに
  • 0.1.1 目的設定
  • 0.1.1.0 観察
  • 0.1.1.1 明確化
  • 0.1.1.2 解決策の立案
  • 0.1.2 モデリング
  • 0.1.2.0 モデルの種類
  • 0.1.2.0.0 データキャリアモデル
  • 0.1.2.0.0.0 プライマリモデル
  • 0.1.2.0.0.1 セカンダリモデル
  • 0.1.2.0.0.2 リレーショナルモデル
  • 0.1.2.0.0.3 ハイブリッドモデル
  • 0.1.2.0.1 オペレーショナルモデル
  • 0.1.2.0.1.0 統合モデル（ブローカー）
  • 0.1.2.0.1.1 処理モデル（サービス）
  • 0.1.2.0.1.2 公開モデル（公開機能）
  • 0.1.2.0.2 構成モデル
  • 0.1.3 シミュレーション
  • 0.1.4 まとめ
• 0.2 原則
  • 0.2.0 人を第一に
  • 0.2.0.0 シンプルさ
  • 0.2.0.0.0 過剰な継承
  • 0.2.0.0.1 絡み合い
  • 0.2.0.0.1.0 水平的な絡み合い
  • 0.2.0.0.1.1 垂直的な絡み合い
  • 0.2.0.0.2 自律的なコンポーネント
  • 0.2.0.0.2.0 マジックを避ける
  • 0.2.1 書き直しやすさ
  • 0.2.2 モノ・マイクロ
  • 0.2.3 レベル0
  • 0.2.4 オープンコード
  • 0.2.5 機内モード（クラウド非依存）
  • 0.2.6 トースターを作らない
  • 0.2.7 引き継ぐ
  • 0.2.8 すべてを含む／すべてを除く
  • 0.2.9 最適化より可読性
  • 0.2.10 最終日

使用するタイミング

ソフトウェアに関する依頼がある場合は、常にこのスキルを使用してください。 アーキテクチャ設計、コーディング、テスト、計画、レビューに着手する前に使用してください。 別の Standard スキルが適用される場合は、まずこのスキルを有効にし、以降の作業をこれに従わせてください。

アイデンティティと理論

0. すべてのシステムは、明示的か暗黙的かを問わず、理論に基づいています。
1. The Standard は三位一体理論を基盤としています。
2. すべてのシステムを、次の3つの観点から理解する必要があります。
   • 目的
   • 依存関係
   • 公開
3. 三位一体はフラクタルです。
   • 同じパターンが、システム、サブシステム、サービス、検証、公開の各レベルで繰り返されます。
4. すべてはつながっています。
   • あらゆる部分を、誰かの依存先または公開対象になることを意識して設計してください。

必須のエンジニアリング手順

次の順序を意図的に守ってください。

0. 目的設定
1. モデリング
2. シミュレーション

開始時にはこの順序が必須です。 後から反復することはできますが、目的を飛ばしてコードに着手してはいけません。

目的設定のルール

0. 観察から始めます。
   • 実際の障害要因、制約、または満たされていないニーズを特定します。
1. 問題を明確に表現します。
   • 必要に応じて、言葉、図、またはイラストを使います。
   • 問題を適切に説明できれば、解決の半分は達成したも同然です。
2. 目的には解決策の立案も含めます。
   • 目標に至る道筋を簡単なものとして扱ってはいけません。
   • 解決策は、可読性、設定可能性、長期的な存続性、最適化、保守性も尊重する必要があります。
3. 目標に到達するために、決して手を抜いてはいけません。
   • 誤った方法で目標に到達することは違反です。
4. 常に目的を明確に保ちます。
   • 目的が不明確な場合は、モデリングや実装に進まず、立ち止まって明確にしてください。

モデリングのルール

0. 目的が必要とするものだけをモデル化します。
1. 無関係な属性をモデルに取り込まないでください。
2. モデルは、問題に必要なデータだけを表現するクラスとして扱います。
3. 問題の範囲に適合する、最も汎用的で妥当な名前を優先します。

データキャリアモデルのルール

0. プライマリモデルは自己完結しています。
   • 存在するために、物理的に別のモデルに依存することはありません。
1. セカンダリモデルはプライマリモデルに依存します。
   • 通常、別のモデルを参照するか、その内部にネストされています。
2. リレーショナルモデルは、2つのプライマリモデルを接続します。
   • 多対多の関係を具現化するために存在します。
   • 無関係な詳細ではなく、参照を保持する必要があります。
3. ハイブリッドモデルは、必要な場合に限り許可されます。
   • リレーショナルな動作と、関係に関する追加の詳細を組み合わせます。
   • まず純粋さを優先し、業務フローで本当に必要な場合にのみハイブリッドモデルを使用してください。

運用モデルのルール

0. インテグレーションモデルはブローカーです。
1. プロセッシングモデルはサービスです。
2. エクスポージャーモデルはエクスポーザーです。
3. コンフィギュレーションモデルは、起動、コンポジション、ミドルウェア、またはエントリーポイントのモデルです。

シミュレーションのルール

0. シミュレーションとは、モデル同士の相互作用です。
1. モデルは別のモデルに作用できます。
2. モデルは別のモデルから作用を受けることができます。
3. モデルは自身に作用できます。
4. 関数、メソッド、ルーチンはシミュレーションの仕組みです。
5. シミュレーションは、その目的とモデルの境界内に収めてください。

中核となる原則と譲れない事項

人を第一に

0. ユーザーと将来のメンテナーの双方のために構築します。
1. 気の利いた仕組みよりも、人間が理解しやすいことを優先します。
2. 一般的なエンジニアが所有し、進化させ、書き直せるシステムを優先します。

シンプルさ

0. シンプルさは必須であり、任意ではありません。
1. シンプルさによって書き直しやすくなります。
2. シンプルさを重視し、モジュラーモノリスと明確な分割を優先します。

過剰な継承

0. 継承は1階層を超えて使用しないでください。
1. フローの垂直バージョニングに絶対に必要な場合を除き、1階層を超える継承は過剰であり、禁止されています。

絡み合い

0. 水平方向の絡み合いを避けてください。
   • Utils は使用しないでください。
   • Commons は使用しないでください。
   • 何でも簡単にすると装う Helpers は使用しないでください。
   • 独立したフロー間でモデルを共有しないでください。
   • 無関係なフロー間で例外や検証ルールを共有しないでください。
1. 垂直方向の絡み合いを避けてください。
   • ネイティブまたは外部のものを除き、ローカルなベースコンポーネントは使用しないでください。
   • 隠れた結合を生み出すローカルな継承チェーンは使用しないでください。
2. 重複によって自律性を保てる場合は、フロー間の絡み合いより重複を優先してください。

自律的なコンポーネント

0. すべてのコンポーネントは自己完結している必要があります。
1. すべてのコンポーネントは、そのいずれかの側面に検証、ツール、ユーティリティを備えます。
2. コンポーネントは、隠れたヘルパーではなく、注入された依存関係に依存できます。
3. 所有権と自律性を保てる場合、重複は許可されます。

マジックなし

0. 見たままがすべてです。
1. 隠れたルーチンは使用しないでください。
2. 参照をたどる必要がある、魔法のような拡張は使用しないでください。
3. システムを理解しにくくする実行時の仕掛けは使用しないでください。
4. 検証、例外処理、トレース、セキュリティ、ローカライズ、動作は、明確に見える場所に記述してください。

書き直しやすさ

0. すべてのシステムは、理解、変更、全面的な書き直しが容易でなければなりません。
1. Standard に準拠したシステムは、予想外のことを最小限に抑えて、フォーク、クローン、ビルド、テストできる必要があります。
2. 隠れた依存関係は認められません。
3. 不明な前提条件は認められません。
4. 動作を不明瞭にする注入ルーチンは認められません。

モノマイクロ

0. マイクロサービスの考え方でモノリスを構築します。
1. すべてのフローは、後から抽出できる程度に自律している必要があります。
2. 早すぎる分割を避けながら、積極的にモジュール化してください。

レベル0

0. コードは、初級エンジニアが理解できなければなりません。
1. 成功の尺度は、レベル0の理解です。
2. 新しいエンジニアがシステムを理解できない場合、そのシステムは複雑すぎます。

オープンコード

0. 可視性とアクセス性の高いコード、ツール、プラットフォーム、パターンを優先してください。
1. 個人または組織の利益だけを理由に、ソースをプロプライエタリにしないでください。
2. 例外が認められるのは、安全性、セキュリティ、または契約上の義務で必要となる場合に限られます。

機内モード（クラウド非依存）

0. クラウドへの依存を必須とせず、システムをローカルで実行できるようにします。
1. クラウドのリソースをローカルの代替手段につなぐツールを開発します。
2. ローカルでのテスト、ローカルでの開発、外部システムのモックを優先します。

お節介なツールは使わない

0. スタイルチェックツールやアナライザーを主な手段として、Standardへの準拠を強制しないでください。
1. Standardを人から人へ伝えてください。
2. 強制よりも、信念と理解を大切にしてください。
3. 「バイブコーディング」を含むAI支援コーディングは認められます。ただし、人間が積極的に関与し、最終的なコードに対する全責任を持つ必要があります。
4. AIをコードレビューや提案に利用してもかまいませんが、承認とマージの判断を下す最終的な権限は、必ず人間にあります。

次の人へ伝える

0. Standardは無償で教えるものです。
1. Standardを教えて利益を得ようとしてはいけません。
2. Standardを使って他者を見下してはいけません。
3. 自由に次の人へ伝えてください。

すべて取り入れるか、すべて取り入れないか

0. Standardは全面的に受け入れるか、全面的に拒否する必要があります。
1. 部分的な採用は標準化ではありません。
2. 古くなった部分的な準拠では、システムがStandardに準拠しているとは主張できません。

最適化より読みやすさ

0. 迷ったら、読みやすさを選んでください。
1. 読みにくい「最適な」ソフトウェアは、本当の意味で最適とは言えません。

最後の日

0. プロジェクトに携わる最後の日かもしれないというつもりで、毎日取り組んでください。
1. エンジニアリングの各日の終わりには、適切な区切りをつけてください。
2. 翌日、別のエンジニアがスムーズに作業を引き継げるようにしてください。
3. これは設計、開発、ドキュメント作成、自動化に適用してください。

エージェントに求められる必須の動作

0. 目的を決して見失わないでください。
1. 目的やモデルが明確でないときに、実装から始めてはいけません。
2. 読みやすさを犠牲にして最適化してはいけません。
3. 隠れた共有抽象化を、最初の手段として決して推奨してはいけません。
4. 理解の代わりに、アナライザーや「お節介なツール」を推奨してはいけません。
5. 曖昧または混沌とした設計は拒否してください。
6. 明示性、自律性、書き直しやすさを優先してください。
7. Standardの用語を一貫して使ってください。
8. 一般的な慣習とStandardが衝突する場合は、Standardを優先してください。