strategic-programming

戦略的プログラミング

システムを、より理解しやすく変更しやすい状態に保ちます。重要な設計、安全性、運用上の特性を維持する、必要最小限の独自の仕組みで、受け入れられた動作を実現します。

以下の観点を、状況に応じて適用してください。これらは品質基準であり、固定された作業手順ではありません。単純化の前に理解を深め、書き込みのたびに、その最終結果を検証します。

変更の根拠を固める

受け入れられた実装の入力（ユーザーからの範囲が明確な依頼、または受け入れられた仕様）、適用されるプロジェクトの指示、コーディング規約、実行可能なゲート設定を読みます。名前が挙がったファイルだけを根拠にせず、影響を受ける接点を通じて、実際の呼び出し元、状態、データの流れをたどります。

編集の前に、受け入れられた各要件と保護すべき動作を明確にし、自動ゲートでは確認できない義務も含めて、予定する検証の証拠に対応づけます。受け入れられた仕様に記載された例を再利用します。範囲が限定された作業であれば、会話内の簡潔な概要で十分です。調査によって影響を受ける義務が判明したら、対応づけを更新します。

変更を律する不変条件またはポリシー、その正式な根拠、その所有者、詳細な知識を持つべきでない呼び出し元を特定します。報告された経路だけが問題のすべてだと決めつけず、兄弟関係にある呼び出し元も調べ、最も狭く正しい接点で欠陥を修正します。

取り消し可能な実装上の選択は、局所的に解決します。証拠によって受け入れられた動作、公開契約、機密性の高いポリシー、または変更コストの高いアーキテクチャが成立しないと分かった場合は、作業を黙って再設計せず、その具体的な不一致を提示します。

自ら抱える仕組みを最小限にする

処理の流れを理解したら、受け入れられた動作を完全に満たす最初の選択肢で止めます。

1. 削除、直接的な組み合わせ、または既存の機能によって、新しい仕組みを避けます。
2. リポジトリで確立された実装またはパターンを再利用します。
3. 標準ライブラリを使います。
4. プラットフォーム標準の機能を使います。
5. すでにインストールされている依存関係を使います。
6. 動作に実際に必要な最小限の独自実装を追加します。

単純明快なコードと、実証されたバリエーションを優先します。将来の仮定に備えて、推測に基づく抽象化、設定、拡張性、ひな型、依存関係を追加してはいけません。

差分が最短だからといって、最良の設計とは限りません。内部実装を増やすことで、呼び出し側に見えるインターフェースが大幅に小さく、より安全になるなら、その追加は正当化されます。受け入れられた動作、判別力のある証拠、信頼境界での検証、セキュリティ、データ損失の防止、アクセシビリティ、必要な運用上の制御を、最小化のために削ってはいけません。

複雑さを隠す

各ポリシーに、明確な置き場所を一つ設けます。内部の実装詳細を大幅に隠し、変更されやすい知識を呼び出し元に持たせない、小さく誠実なインターフェースを持つ、深いモジュールを優先します。削除テストを使います。モジュールを取り除くと複雑さが呼び出し元に広がるなら、そのモジュールには深さがあります。複雑さそのものが消えるなら、そのモジュールは単なる中継役かもしれません。

システムが依存する区別を保てる名前と型を使います。未知の外部データや永続化データは境界で解析・検証してから、安全なアプリケーション型で処理します。付随的なシグナルから再構築するのではなく、正式な事実を保持します。

共有された可変状態、並行処理、順序、再試行、所有権の移譲、ロールバック、移行、復旧、または他のフィールドの形を変えるフィールドが正しさに影響する場合、実装前に状態空間を列挙します。つまり、各操作の結果、順序、または変更について、それが遭遇しうる各状態に対する振る舞いを、遅延、反復、部分的な成功、失敗を含めて列挙し、受け入れられる結果を明示します。そこからテストを導き、所有者とアトミックな境界を明確にします。変更に存在しない相互作用の要素に対しては、仕組みを追加しません。

挙動を証明する

各重要な義務を、忠実さを保てる最も限定的な接点に対応づけます。以前の挙動や、起こり得る不具合で失敗するテストまたは再現手順を維持し、期待される結果は、受け入れ済みの契約、具体的な例、既知の正常なフィクスチャ、外部のオラクル、または実装と異なる結論を出し得る別の情報源から導きます。

テストを作成または維持する前に、テストの価値を適用します。4つの質問、価値のないパターン、維持するための基準を確認してください。

完了を宣言する各担当者は、引き渡す状態の検証に責任を持ちます。最後に編集した後、または編集が不要だった場合はレビュー後に、該当する対象を絞ったテストと、影響を受けるプロジェクトのゲートを実行します。実行可能なプロジェクト設定で変更コードの複雑さチェックが定義されている場合は、それも含めます。他の担当者が以前に得た成功の証拠で代用したり、既知の失敗を後のレビューに先送りしたりしてはいけません。存在しないプロジェクトツールやしきい値を作り出してはいけません。

戦略的に仕上げる

対象を絞った検証が成功したら、変更の波及、隠れた詳細に関する呼び出し元の知識、ポリシーの重複、不誠実な名前や型、回避できる独自の仕組み、適切な置き場所が明確でない失敗時の挙動がないか、結果を確認します。受け入れ済みの範囲内で、裏付けのある不具合を修正し、その後、影響を受ける証拠を再確認します。

複数の不具合が共通の原因を持つ場合は、最も強力な構造的修正でその原因を解消します。優先順位は、不正な状態を表現不能にする型、リンターまたはアーキテクチャルール、仕組みを担う共有コンポーネント、判断を要する事柄に対するコーディング規約の順です。新しいチェックを追加するより、既存のチェックを強化してください。新しいチェックが報告する既存の違反を修正するか明示し、仕込んだ違反に対してチェックが失敗することを証明してください。

最終結果を、グラウンディングで作成した義務の対応づけと照合します。自動ゲートの対象外も含め、観察された証拠または明示的な制限によって、各義務への対応を示します。完了を宣言する前に、対象範囲内の既知の見落としを解消してください。

解決されていないリスクを報告するのは、修正が受け入れ済みの境界を越える場合に限ります。根拠となる証拠、結果、必要な判断を明記し、推測に基づくフォローアップ項目の一覧を作ってはいけません。

境界

• このスキルが定めるのはプログラミングの品質であり、提供の順序、役割、コミット、提供状態ではありません。
• プロジェクトのコーディング規約、実行可能なゲート、受け入れ済みの仕様、またはその受け入れテストに取って代わるものではありません。
• 副作用として ADR、用語集、標準ファイル、エージェント向け指示を作成または更新するものではありません。
• 行数、ファイル数、抽象化の数、テスト数は診断上の指標であり、それ単独でゲートになるものではありません。

完了基準

受け入れ済みの挙動が適切な接点に実装されていること。重要な不変条件が、独立した識別力のある証拠で裏付けられていること。適用可能なゲートが担当者の最終状態に対して成功していること。重要な複雑さが誠実なインターフェースの背後に隠されていること。回避できる仕組みや、対象範囲内の既知の不具合が残っていないこと。