ロブ・パイクのプログラミング規則（1989年）

• 1989年のRob Pikeによる、プログラミングの5つの規則に関する記事
• 規則1: プログラムがほとんどの時間をどこで費やすかを決めつけてはならない。ボトルネックは予想外の場所で発生しうる。ボトルネックが実証されるまで速度ハックは避けよ。
• 規則2: 速度のためにチューニングする前に、必ず測定せよ。コードの一部が残りに大きな影響を与える場合にのみ最適化せよ。
• 規則3: n が小さいとき、複雑なアルゴリズムは遅い。たいていの場合はこれに当てはまる。n がしばしば大きい場合にのみ複雑なアルゴリズムを使い、その場合でもまず規則2を適用せよ。
• 規則4: 単純なアルゴリズムとデータ構造が望ましい。複雑なものよりバグに弱くなく、実装もしやすい。
• 規則5: 正しいデータ構造はプログラミングにおいて決定的である。データが適切に構成されていれば、アルゴリズムは自明になる。
• Pikeの規則1と2は、Tony Hoareの格言「早すぎる最適化は諸悪の根源である」を反映している。
• Ken Thompsonは、Pikeの規則3と4を「疑わしいときは brute force を使え」と言い換えた。
• 規則3と4は、KISS（Keep It Simple, Stupid）という設計哲学を体現している。
• 規則5は、Fred Brooksの『The Mythical Man-Month』での発言と一致しており、しばしば「賢いオブジェクトを使う愚かなコードを書け」と要約される。

[GN⁺]

Hacker Newsの意見

• 1989年のRob Pikeのプログラミング規則に関する記事
• コメント投稿者たちは、プログラミングの核心はアルゴリズムではなくデータ構造だという点に同意
• LeetCodeの面接がアルゴリズムよりデータ構造に焦点を当てていないことへの批判
• nが小さいときは複雑なアルゴリズムは遅く、たいていの場合nは小さいという主張
• コメント投稿者たちは、適切なデータ構造の選択と物事をうまく整理することの重要性を強調
• データベースの誤用と、ORMが生成したDBスキーマの悪影響に関する議論
• ガイドラインは、過剰なエンジニアリングと性急な最適化を防ぐための戦略に見える
• 一部のコメント投稿者は、わずかな性能の無駄でも積み重なればプログラムを遅くしうると主張
• 「性急な最適化はすべての悪の根源」という引用と、その文脈をめぐる議論
• 優れたプログラマーは何が遅くなるかを予測し、あらかじめ教育的な賭けができると主張するコメント投稿者もいる
• 単純なデータに対する複雑なアルゴリズムが大きな性能向上をもたらし、さらには単純化にさえつながるという反論
• この記事が、一部の読者の設計と複雑さに対するアプローチに継続的な影響を与えている
• 規則5の解釈をめぐる議論、「スマートなオブジェクトを使う愚かなコードを書け」という文言に対する見解の相違もある