rob-pike

Rob Pike のプログラミングに関する 5 つのルール

ルール

1. プログラムがどこで時間を費やすかは、事前にはわかりません。 ボトルネックは意外な場所に発生します。推測せず、実証してください。
2. 測定してください。 測定するまでは速度を調整しないでください。測定した後でも、コードの一部分がほかを圧倒している場合に限ります。
3. 凝ったアルゴリズムは n が小さいと遅く、たいてい n は小さいものです。 定数項が支配的な場合、ビッグオー記法は重要ではありません。まずルール 2 を適用してください。
4. 凝ったアルゴリズムは、単純なものよりバグが多くなります。 単純なアルゴリズムと単純なデータ構造を使ってください。
5. データがものを言います。 適切なデータ構造を選べば、アルゴリズムは自ずと明らかになります。「賢いオブジェクトを使う、愚直なコードを書きましょう。」

適用方法

最適化を始める前に

ステップ 0：既存の計測機能を確認する

「測定しましたか？」と尋ねる前に、まず現時点で測定が可能かどうかを確認してください。

コードベースをスキャンして、既存の計測機能の痕跡を探してください。

• ロギング：ロガーのインポート、ログ呼び出し、構造化ロギングライブラリを探します
• プロファイリング：プロファイラーのインポート、ベンチマークファイル、トレーシングの設定を探します
• 時間計測：処理時間の測定、ストップウォッチのパターン、時間計測デコレーターを探します
• APM／オブザーバビリティ：メトリクスのエクスポート、スパン、トレースコンテキストを探します

次に、ユーザーに尋ねてください。

1. 計測機能がある場合：「[locations] にロギング／プロファイリングが見つかりました。遅いと思われる箇所はありますか？ それとも、既存の測定結果を確認しましょうか？」
2. 計測機能がない、または不十分な場合：「処理時間の使われ方を実証するための測定手段がありません。何かを最適化する前に、ボトルネックはどこだと思いますか？ まずそこに計測機能を追加して、データに判断を委ねましょう。」

特定のツールを推奨することが目的ではありません。Claude は、その言語に適したプロファイリング方法をすでに把握しています。目的は、最適化について話し合いを続ける前に、計測手段があることを確認することです。測定に使えるものが何もないなら、最初に行うべきことはコードの変更ではなく、計測機能の追加です。

ステップ 1：測定に関する質問をする

立ち止まって、次の質問を順番に確認してください。

1. 「測定しましたか？」 — まだなら、まず測定してください。測定データのない最適化は時期尚早です。プロジェクトの言語やエコシステムに適したプロファイリングツールを使ってください。
2. 「一部分がほかを圧倒していますか？」 — 特定の箇所が支配的でなければ、最適化する価値はありません。複数の箇所に分散した小さな改善が、大きな効果をもたらすことはほとんどありません。
3. 「n の値はいくつですか？」 — n が小さい場合（たいていは小さいものです）、定数項、キャッシュの挙動、実装の複雑さを考慮すると、単純な O(n²) の方法が巧妙な O(n log n) の方法を上回る可能性があります。
4. 「これはデータ構造の問題ですか？」 — アルゴリズムを変更する前に、別のデータ構造を使えば問題が自明に解けないか検討してください。適切なデータ構造を使えば、巧妙なアルゴリズムがまったく不要になることもよくあります。
5. 「追加される複雑さに見合う価値がありますか？」 — 10％遅い単純なコードは、壊れやすく保守しにくい巧妙なコードよりも、ほとんどの場合望ましいものです。

避けるべきアンチパターン

次のいずれかを自分やユーザーがしようとしていることに気づいたら、立ち止まって別の方向へ導いてください。

衝動	違反するルール	対応
「このループは遅そうなので、最適化しましょう」	ルール 1	プロファイリングしましたか？ ボトルネックはまったく別の場所かもしれません。
「ここにキャッシュを追加しましょう」	ルール 2	まず測定してください。この処理経路が実際に実行時間を支配していますか？
「B ツリー／トライ／スキップリストを使いましょう」	ルール 3	n の値はいくつですか？ 小さいなら、ソート済みスライスと二分探索のほうが適しています。
「カスタムアロケーターを実装しましょう」	ルール 4	まず単純な方法から始め、測定してください。データが必要性を示す場合にだけ凝った方法を使ってください。
「アルゴリズムが O(n²) なので、修正が必要です」	ルール 3	n の値はいくつですか？ n=100 の O(n²) は 10μs です。まず測定してください。
「並列化しましょう」	ルール 2	実際に CPU バウンドですか？ 測定してください。多くの場合、I/O が原因です。

最適化が正当化される場合

以下のすべてに当てはまる場合に限り、最適化を進めてください。

• 特定のボトルネックを示す測定データがある
• そのボトルネックが全体の実行時間の大部分を占めている（わずか5～10％ではない）
• 提案する修正が、測定された問題に対処する最もシンプルな変更である
• 変更後に再測定して、改善を確認する