ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール5最適化に関する教訓その1は、「最適化するな」

　プログラミング上の作業の中でも、ぼくのお気に入りなのは、最適化だ。通常は、何らかのコードのシステムがもっと高速に動作するよう手を加えることを意味するが、時には、メモリー使用量やネットワーク帯域幅やその他のリソースを最適化することもある。

　最適化がぼくのお気に入りの作業である理由は、成功度合いの計測が単純だからだ。ほとんどのコーディング作業では、何をもって成功とするかは曖昧になっている。本書みたいな数々の書籍が、良いコードや良いシステムとはどんなものなのかを一生懸命定義しようとしているものの、何をもって1行のコードを良いとするのかは、不明確なのが常だ。

　最適化については、そんなことはない。最適化の場では、答えはもっと鮮明だ。何かをもっと速く動かそうとするなら、その成功度合いを直接計測できる。その成功に伴う、コードのサイズや複雑性の増大という形で出てくるコストについても、同じことが言える。中途半端に定義された長期的利益のことを心配したりしないでいい。きみの新しいコードを数年後に読んだ誰かが、そのコードをすぐ理解して、プログラマーとしてのきみに対する感謝感激の波に押し流されるだろう……みたいなことを確信できるようにコードを整えたりしなくてもいい。目に見える成果が直ちに出るってだけのことだ。

　最適化が好きなのは、ぼくだけじゃない。実際、プログラマーなら誰でも知ってるプログラミングの格言を1つ生み出すきっかけになるほど、最適化っていう作業は魅力的だ。

早まった最適化は諸悪の根源である。

　ちなみに、これは引用文の全体じゃない。原文は、1974年にDonald Knuth†1が書いていて、もっと多様な意味を含む。