コード最適化
ユーザーから見えるパフォーマンスと信頼性を向上させ、コードを理解しやすく保ち、運用コストを適切に保ちます。存在するワークロードを最適化し、仮定の将来の規模のために複雑さを追加しないでください。
ワークフロー
- 目標とガードレールを定義する。 関連するエンドポイント、ジョブ、クエリ、ワークロード、および望ましい結果を特定します。重要なメトリクスのみを選択します。例：p95/p99レイテンシ、スループット、CPU、メモリ、割り当てレート、データベースクエリ数、依存関係のラウンドトリップ、エラーレート、飽和状態など。動作、一貫性、セキュリティ、既存のエラー契約を維持します。不足しているターゲットやワークロードが適切な選択を妨げる場合にのみ、1つの焦点を絞った質問をします。それ以外の場合は、リクエストとコードから推論できる情報を使用します。
- ベースラインを確立する。 既存のトレース、プロファイル、クエリプラン、メトリクス、テスト、または代表的なベンチマークを使用します。変更の前後で入力、環境、同時実行性を同等に保ちます。直感や単一のノイズの多いタイミングから速度向上を主張しないでください。許可なく本番環境に対して負荷テストや高コストなクエリ分析を実行しないでください。
- ボトルネックを見つける。 エンドツーエンドのクリティカルパスをトレースし、プロファイリングまたは計装を使用して、CPU処理、ブロッキング、データベース時間、ネットワーク待機、シリアライゼーション、ロック競合、キューイングを区別します。実際のクエリ/呼び出しパターンと代表的なデータを検査します。大まかなクリーンアップやマイクロ最適化よりも証拠を優先します。ボトルネックが確立されていない場合は、不確実性を報告し、侵襲的な変更を行う前に最小限の有用な測定を提案します。
- 最小限の効果的な変更を選択する。 実用的な場合、一度に1つの重要なボトルネックを最適化します。出力、順序、失敗動作、トランザクションセマンティクス、セキュリティチェックを維持します。ベンチマークでの勝利のために正確性や信頼性を犠牲にしないでください。リポジトリの規約に従い、無関係なリファクタリングを避けてください。
- 両方の結果を検証する。 関連する正確性テストを実行し、変更の前後で同じ代表的なワークロードを比較します。ターゲットメトリクスが改善されたこと、およびガードレール（特にテールレイテンシ、エラー、メモリ、依存関係の飽和状態）が悪化していないことを確認します。意味のある比較が利用できない場合は、その旨を述べ、未測定の変更を証明された最適化として提示しないでください。
- 結果を報告する。 ボトルネックと証拠、行われた変更または推奨、検証と測定された影響（または測定できなかった理由）、および重要なトレードオフを簡潔に述べます。監査または計画リクエストの場合は、コードを変更する代わりに、証拠、推定される影響、労力、リスクによって調査結果を優先順位付けします。
データベースとデータアクセスの最適化
- クエリをカウントし、ORM/データベースアクセスパターンを検査します。適切な結合、バッチ、またはセットベースの操作でN+1読み取りまたは書き込みを削除します。クエリ数を検証し、結果の順序と欠落レコードの動作を維持します。
- 必要な列と行のみをフェッチします。大きな結果セットにはページネーションまたはストリーミングを使用します。アプリケーションメモリに大きなデータセットをロードする代わりに、適切なフィルタリングと集約をデータベースにプッシュします。
- クエリプランと実際の述語を使用してインデックスを正当化します。選択性、ソート/結合のニーズ、既存のインデックス、書き込み/ストレージのオーバーヘッドを確認します。推測的または重複したインデックスを追加しないでください。代表的なデータでプランとレイテンシを検証します。実行ベースのプラン分析は安全な環境でのみ使用します。
- 不要なラウンドトリップを削減し、トランザクションとロックのスコープを必要以上に大きくしないでください。ショートカットとして制約、分離、検証、一貫性を弱めないでください。
- 測定された再利用が正当化される場合にのみキャッシュを追加します。鮮度、無効化、キースコープ、障害動作を定義します。遅いクエリに対するデフォルトの応答としてキャッシュを導入しないでください。
バックエンドとサービスコールの最適化
- 冗長な呼び出しを削除し、互換性のあるリクエストをバッチ処理し、真に独立している呼び出しのみを並列化します。同時実行性を制限し、必要な順序/依存関係を維持し、ダウンストリームのキャパシティを考慮します。
- クライアントと接続プールを再利用します。リクエスト予算に適合する期限/タイムアウトを設定し、サポートされている場合はキャンセレーションを伝播します。
- 操作が再試行しても安全な場合にのみ、一時的な障害を再試行します。試行回数と再試行の合計時間を制限し、ジッター付きのバックオフを使用し、負荷を増幅する方法で複数のレイヤーで再試行しないでください。対処する実証済みの障害モードがない限り、再試行、サーキットブレーカー、キューを追加しないでください。
- ペイロードが大きすぎる場合やシリアライゼーションの繰り返しは、それらが測定されたパスに重要な場合にのみ削減します。必要なサービス障害セマンティクスをそのまま維持します。オプションの依存関係には明示的にグレースフルデグラデーションを行います。
ランタイム、信頼性、保守性
- 証拠によってサポートされる最も効果の高い修正を優先します。アルゴリズムの複雑さを改善し、繰り返し作業を削除し、不必要な割り当て/コピーを削減し、低レベルのマイクロ最適化の前にブロッキングと競合に対処します。
- 同時実行下でリソース使用を制限します。メモリ、キュー、プール、ファンアウト、タイムアウト、キャンセレーション、バックプレッシャーを考慮します。障害が再試行ストーム、無制限の作業、リソースリークを引き起こさないようにします。
- パフォーマンスと信頼性をシステムレベルの成果として扱います。データベースに過負荷をかけたりエラーレートを増加させる高速な呼び出し元は最適化ではありません。
- YAGNIを適用します。仮定のボトルネックのために依存関係、抽象化、キャッシュ、インデックス、非同期レイヤー、設定オプション、アーキテクチャ変更を追加しないでください。明確なローカル変更を優先します。複雑さが必要な場合は、測定された利点とそのメンテナンスコストを説明します。
- 無視できる時間を節約するために、入力検証、認可、可観測性、セキュリティチェックを削除しないでください。測定された利点が重要でない限り、読みやすいコードをより保守が難しいマイクロ最適化に置き換えないでください。
検証に関する注意事項
- 同等のワークロードを、再現可能な実行と十分なサンプル数で比較し、シグナルとノイズを区別します。平均だけでなく、関連する場合は分布（特にテールレイテンシ）を使用します。
- バッチ処理、キャッシュ、並列処理、ページネーション、再試行、同時実行性によって影響を受ける機能的な動作とエッジケースを検証します。クエリ数、順序、タイムアウト動作、オプションサービスのフォールバックなど、意味のある不変条件を保護する焦点を絞ったテストを追加します。
- 変更後に再プロファイリングします。ボトルネックは移動します。ローカルな改善によってコストが別のサービスやリソースに移行する可能性があります。
- 最適化が重要な改善を生み出さない場合、またはその複雑さが利点を上回る場合は、それを元に戻すか、反対することを推奨します。