最適化 (情報工学)
ソフトウェア開発プロジェクトでは、コード最適化は新たな機能を追加するわけでもなく、失敗すれば既存の機能を壊してしまうこともある。最適化されたコードの可読性は低いので、最適化によってプログラムの保守性が損なわれることもある。「リファクタリング」と同様に、機能が保存されていることのテストが少なくとも必要とされる。
トリビアルな覗き穴最適化などはある程度以上のコンパイラならば実装しており、プログラマが手作業でそれと同等程度の最適化を施すのはバグの元でしかなく、意味が無いだけでなく有害である。例えば x = a + b * 4 のようなコードを x = a + b << 2 のように「最適化」してしまうのが典型的な失敗例であり、こういった最適化をプログラマの良い習慣であると評価しているような組織があったらそれはある種のシグナルである。
プログラマのリソースを消費して最適化を行うのではなく他の手段に頼るほうがコストパフォーマンスが良い場合がある。例えばWebアプリケーションの場合に最適化するのではなくサーバースペックの強化で対応したり、分散可能な場合にサーバー台数の増加で対応する。メモリ断片化やメモリリークの原因特定と修正を試みるよりも定期的に再起動するなど運用方法の変更で対応する。画像や映像処理は最適化余地の少ないCPU上で動作させるコードを最適化するのではなくGPUなど特化したハードウェアを用いるなど。
インタプリタな処理系(特にPHPのように繰り返し実行され、性能も要求される場合)では、プログラマはコードからコメントや空白を削除し、使われないメソッドや関数の定義を削除してから、コードを配備することがある。これはネットワーク上の転送時間やインタプリタがコードを読み込む時間を少しでも改善しようという一種の最適化である。
このとき、元のコード(コメント付きの整ったコード)を捨ててしまうと、保守性が犠牲となる。そのようなコードは可読性が低く、デバッグや修正や改造が困難となる。従って、元のコードを手元に残しておくことが推奨され、修正を加える必要がある場合は、その元のコードを使うのがよい。
また、コメントや空白を削除することが実行時間の短縮に寄与するかどうかは事前に確かめておく必要がある。場合によっては「労多くして、益少なし」となることもある。一般にソースコードをネットワーク上で転送する JavaScript などのコードの方が、ローカルに実行されるPHPなどよりも効果が大きい。
最適化ではコードの可読性を損ない、性能向上にしか寄与しないコードを追加することがある。これはプログラムやシステムを複雑にし、保守やデバッグがしにくくなる。そのため、最適化や性能チューニングはソフトウェア開発工程の最後のほうで行われることが多い。
ドナルド・クヌースは、時宜を得ない(しばしば、早すぎる段階での)最適化を戒める言をいくつも記している。一例を挙げれば、
「ほんとうの問題点は、プログラマたちが誤った場所と誤った時点での効率について苦労して、多くの時間を浪費してしまったということにあります。プログラミングでは、時を得ない最適化は諸悪の根源なのであります。(すべてではないにしても、少なくとも悪の大部分と言えるでしょう。)」(1974年、チューリング賞受賞講演より。『ACMチューリング賞講演集』p. 56、『文芸的プログラミング』p. 30)
クヌースはアントニー・ホーアに由来するとしているが、ホーアは否定している(アントニー・ホーア#語録を参照)。ダイクストラに由来するのではないかとする説があり、ホーアもそう述べている。なお、クヌースが1974年に「未熟な最適化は諸悪の根源である」と書いているもうひとつの文献は、ダイクストラのGo To Statement Considered Harmfulに対して書かれた、Structured Programming with go to Statementsである。