コード品質パターン


Well-Architected Resource and Cost Optimization (適切に設計されたリソースとコストの最適化) → コードの整理

この統合パターンページでは、リソース最適化のコード品質とメンテナンス性プラクティスについて説明します。これには、標準コードとカスタムコードの決定、技術的負債管理、設計標準、ドキュメント作成方法、ガバナンスに関するガイダンスが含まれます。これらのパターンは、開発速度の維持、不具合率の低減、長期的なソリューションの持続可能性の実現に役立ちます。

パターン

参照すべき場所外観
規模に応じたパフォーマンス✅ テストでは、宣言型ソリューションが予測されるデータ量のパフォーマンス要件を満たしていることを確認します。Full Copy Sandbox で現実的なデータを使用して負荷テストを行い、本番リリース前の拡張性を確認します。
メンテナンス性分析✅ TCO 分析では、アップグレード作業、テスト要件、将来のチームのスキル要件など、宣言型アプローチとカスタムアプローチの長期的なメンテナンス負荷を比較します。
混合アプローチアーキテクチャ✅ ソリューションは、必要に応じて宣言型アプローチとプログラム型アプローチを組み合わせます。フローで概要レベルのロジックを調整し、Apexで複雑な計算を処理します。Apex で一括操作が処理される間、数式項目は単純な派生を計算します。
AppExchange 評価✅ カスタムコードを作成する前に、同様の機能を提供する既存の AppExchange パッケージを評価します。レビュー済みパッケージ、機能ギャップ、TCO の比較などの評価結果を文書化します。

パターン

参照すべき場所外観
バックログの表示✅ バックログで追跡される技術的負債項目 (明確な表示ラベル付き)、コードの改善が必要な理由を説明するコンテキスト、対処せずに放置した場合のビジネスへの影響、および推定修正工数。目に見えない負債に優先順位を付けたり、管理したりすることはできません。
段階的な改善✅ 機能開発中に適用されるボーイスカウトルール: コードが見つからないままにします。チームは、大規模な専用のリファクタリングプロジェクトを必要とするのではなく、関連する機能作業中に負債を段階的に修復します。コードレビューでは、段階的な改善を確認します。
修復よりも防止✅ CI/CDの品質ゲートは、コードが本番に到達する前に標準を適用します。取り込み要求検証に統合されたコードスキャナー、ApexGuru、および複雑性評価指標。ブロックの問題により、解決するまでマージできません。

アンチパターン

参照すべき場所どんな悪い感じか
バックログ管理⚠️ 口頭で承認されたがバックログで追跡されなかった技術的負債。負債の蓄積を可視化できない。債務修復は、常に機能作業が優先されて延期されます。速度は徐々に低下し、チームはその理由を説明できません。
品質ゲートバイパス⚠️ CI/CD 品質ゲートは、後で修正する意図でスケジュールの圧力で頻繁にバイパスされます。「後」は起こりません既知の問題としてマークされ無視されたコードスキャナーの障害。不適切な実装に対応するために引き上げられた複雑さのしきい値。
修復能力なし⚠️ 技術的債務の修復業務量が 0 のフィーチャー作業に割り当てられるスプリント業務量の 100%。負債は無期限に蓄積されます。大規模なリファクタリングプロジェクトでは、四半期全体にわたって 18 ～ 24 か月ごとに実施する必要があります。
設定負債⚠️ カスタムメタデータ型とカスタム設定はクリーンアップなしで蓄積されます。未使用の設定は無期限に保持されます。本番には 50 件のメタデータレコードがあり、実際に使用されるのは 12 件のみです。設定値の目的を説明するドキュメントはありません。

パターン

参照すべき場所外観
トリガーアーキテクチャ✅ トリガーハンドラーパターンが一貫して適用されます。シントリガーはハンドラークラスに委任され、ハンドラークラスはトリガーコンテキスト (挿入前、更新後) 別にロジックを整理し、明確なメソッド名によって目的を明らかにします。トリガーファイル自体にビジネスロジックはありません。
サービスレイヤーの実装✅ コントローラー、トリガー、バッチエントリポイントとは別のサービスクラスにカプセル化されたビジネスロジック。重複のない複数のエントリポイントで再利用可能なサービスクラス。明確な命名規則 (AccountService、OrderProcessor)。
セレクターパターン✅ オブジェクトごとのセレクタークラス (AccountSelector、OpportunitySelector) で一元化された SOQL クエリ。セレクターメソッドは、一貫した項目セットを返します。LDV 最適化の変更が 1 回適用され、すべてのクエリに影響します。
リポジトリパターン✅ インターフェースの背後で抽象化されたデータアクセスにより、疑似データソースでテストできます。リポジトリの実装では、クエリの構築、キャッシュ、最適化戦略がカプセル化されます。ビジネスロジックは、具体的な実装ではなくリポジトリインターフェースに依存します。
コンポーネント設計標準✅ Lightning Webコンポーネントは、単一責任の原則に従い、構成のプロパティを公開し、親通信のイベントを生成します。これは、構成と再利用を目的として設計されています。使用例が記載されたコンポーネントライブラリ。
コード整理✅ 論理パッケージ構造では、関連クラスがグループ化されます。ドメインロジック、データアクセス、API エンドポイント、インテグレーションアダプターを明確に分離します。パッケージ連動関係は一方向に流れます。

アンチパターン

参照すべき場所どんな悪い感じか
トリガー⚠️ すべてのビジネスロジックがトリガーファイルに直接組み込まれ、深くネストされた条件、懸念の分離、ハンドラークラスがない。検証、ビジネスロジック、インテグレーションコールが混在する 300 を超える品目トリガーファイル。効果的にテストできない。
ループ内のクエリ⚠️ 反復ループ内で実行される SOQL クエリ。データ量が少ない場合は動作しますが、一括処理の処理時に 100 SOQL クエリ制限に違反します。本番の一括データ読み込みでトリガーが起動された場合にのみ検出されます。
ループ内の DML⚠️ 反復ループ内で実行される DML ステートメント (insert、update、delete)。一括操作で 150 DML ステートメントの制限に違反する。各レコードは、効率的な一括処理ではなく、個別のデータベーストランザクションで処理されます。

パターン

参照すべき場所外観
アーキテクチャ決定レコード✅ バージョン管理に保存されている ADR で重要なアーキテクチャ上の決定が文書化されている。ADR は、コンテキスト (ビジネスの推進要因、技術的な制約)、決定 (選択された内容)、検討された代替案 (却下の理由)、結果 (トレードオフ、再訪の条件) を取得します。