【要約】Laws of Software Engineering [Hacker_News] | Summary by TechDistill
> Source: Hacker_News
Execute Primary Source
// Discussion Topic
「早すぎる最適化は諸悪の根源」という格言の再定義。
- ・計算量的な最適化と、アーキテクチャ的な最適化の差異。
- ・抽象化（JVMの参照型等）がもたらす隠れたコスト。
- ・プロファイラやデバッガを用いた定量的測定の重要性。
- ・低レイヤ（ビット、メモリ、CPU命令）への理解不足による弊害。
// Community Consensus
【格言の誤用への批判】
- ・「最適化は後回しで良い」という解釈は、設計の怠慢を正当化する免罪符に過ぎない。
- ・アーキテクチャのミスは、後付けのキャッシュや並列化では解決できない。
- ・ボトルネックは、アルゴリズムよりも通信回数やメモリ配置に存在する。
- ・測定（Profiling）に基づかない最適化は、リソースの無駄である。
- ・デバッガやプロファイラを使いこなせないのは、プロとして致命的。
- ・低レイヤの挙動を予測できない設計は、予測不能なパフォーマンス低下を招く。
// Alternative Solutions
- ・プロファイラ（Datadog等）による定量的測定。
- ・
stdint.h等を用いた、型サイズの明示的な指定。 - ・設計段階でのパフォーマンス予算（Performance Budget）の設定。
- ・テストコードによる、複雑な仕様（タイムゾーン等）の振る舞い担保。
// Technical Terms
Senior Engineer Insight
> 「最適化は後回し」という言葉を、設計の怠慢に対する免罪符にしてはならない。現代のシステムでは、計算速度よりも「データの移動」と「抽象化のコスト」がレイテンシを支配する。アーキテクチャレベルでのミスは、キャッシュや並列化といった「後付けの最適化」では解決できない。我々の現場においても、高レイヤの抽象化を使いこなしつつ、低レイヤの挙動（メモリ、CPU）を正確に予測できる「二刀流」のエンジニアを育成・評価すべきである。設計段階でのパフォーマンス考慮は、最適化ではなく「必須の要件」である。