2026/03/18 18:59
ロブ・パイク『プログラミングのルール』（1989年）
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳:
## Summary この記事は過度な最適化を警告しています。 主なポイント: 1. **ボトルネックは予測できない** – コードの特定部分が遅くなると仮定せず、まず測定する。 2. **調整前に測定する** – あるセクションが明らかに他を支配している場合のみ最適化する。 3. **派手なアルゴリズムに注意** – 大きな定数を伴い、小さな *n* では性能を損なう可能性があります。 *n* が十分大きいことが確認できたら使用し、次にルール 2（規則ベースの正当化）を適用する。 4. **シンプルさが勝る** – 複雑なアルゴリズムは実装が難しく、単純なものよりエラーが発生しやすい。 5. **データ構造が最も重要** – 適切なデータ構造を選ぶことでアルゴリズム自体が明白になることが多く、これがルール 5である。 6. **Hoare の格言** – Pike のルール 1 と 2 は「過度の最適化はすべて悪の根源だ」という考えを反映している。 7. **Thompson の助言** – Ken Thompson はルール 3 と 4 を「疑うときはブルートフォースを使え」とパラフレーズし、KISS（Keep It Simple, Stupid）を体現した。 8. **Brooks の原則** – ルール 5 は Fred Brooks の *The Mythical Man‑Month* に由来し、「賢いオブジェクトを使った愚かなコードを書け」というまとめである。 実務上の示唆: まずベンチマークを行い、次に適切なルール（特にルール 5）を適用してからより洗練された解決策へ進む。この規律あるアプローチは不要な複雑さを避け、バグを減らし、開発速度を向上させ、最終的にはコストを節約する。```
本文
パイクのプログラミング規則
-
「どこで時間を費やすかは分からない」
ボトルネックは思いがけない場所に現れるものです。最初から速度向上策を入れようとせず、実際にボトルネックがそこにあることを証明してから対処してください。 -
「測定する」
速度調整は測定後にのみ行い、さらにそのコードの一部だけが他を圧倒しない限りは控えてください。 -
「n が小さいときは高度なアルゴリズムよりも遅い」
高度なアルゴリズムは定数項が大きく、一般的に n は小さくなることが多いです。n が頻繁に大きくなると分かった時点でのみ、規則 2 を先行して実施してください。 -
「高度なアルゴリズムは単純なものよりバグが多く、実装も難しい」
シンプルなアルゴリズムとデータ構造を併用するのがベストです。 -
「データが支配的」
適切なデータ構造を選び、整理すればアルゴリズムはほぼ自明になります。プログラミングではアルゴリズムよりもデータ構造が重要です。
規則 1 と 2 はトニー・ホアの有名な格言「過剰な最適化はすべての悪の根源」を再表現したものです。
規則 3 と 4 はケン・ソンプスが「疑問があるときは暴力的手段を使え」とまとめた言葉に置き換えることもできます。
これらは KISS（シンプルでいよう） の設計哲学の一例です。
規則 5 はフレッド・ブロックスが The Mythical Man‑Month にて述べたものです。
この規則は「賢いオブジェクトを使った馬鹿げたコードを書け」と省略されることもあります。