1つの解決策を永続的な決定とするのは無理がある――曳光弾とプロトタイプ、ユーザーからのフィードバック：問題解決力を高めるコツはプログラミングの原則・思考にあり（7）（3/4 ページ）

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。プログラマーは唯一の最終決定解を求める傾向にある。しかし最終決定などというものは幻想で、存在しない。いたるところに常に変化は存在する。今回は「曳光弾」「プロトタイプ」によって早くユーザーからフィードバックを得ることの重要性をお伝えしよう。

[上田勲，著]

UNIX思想（15）　最適化の原則

　英語　　Rule of Optimization

　What　〜速いコードより正しいコード

　プログラミングにおける最適化とは、パフォーマンス・チューニングを行うことです。動作スピードを上げたり、メモリやディスクスペースなど、マシンリソースの使用を効率化したりします。

　ただし、プログラミングにおいては、コードを最適化する前に、正しく動作するコードを書くようにします。

　十分に動作するものがない段階で、細かいところを磨いていくことには意味がありません。ごくわずかの成果のために、多すぎる時間を注ぎ込むことになります。

　Why　〜早い段階での「速いコード」は設計を破綻させる

　正しく動作する前に最適化に走ることは、コードの設計を台無しにすることです。

　なぜなら、この時点で最適化にこだわると、以下の問題が起こるからです。

• 透明性や単純性が犠牲になる

　コードが無理なものになったり、コードの内部構造がわかりにくくなったりすると、多くの障害を生み、その障害は莫大な時間を浪費します。そうしてまで得られるものはと言えば、障害のデバッグにかかる時間と比べてはるかに価値の少ない、微々たる高速化や、リソース使用量のわずかな節約に過ぎません。

• 部分に対する半端な最適化が、全体の最適化の妨げになる

　半端に最適化すると、全体に渡る大きな効果が得られる最適化ができなくなります。その結果、パフォーマンスが低い上に、必要以上に複雑なコードが残ることになります。

　How　〜正しくしてから速くする

　まず動かし、正しくしてから、速くしましょう。この順番でプログラミングすることを肝に銘じてください。

　最適化より前に、最適化されていない「遅くて、リソースを大量に消費するが、正しく動作する実装」をしましょう。少なくともこの時点では、コードの複雑度を上げないようにして、シンプルな状態を保ちます。その後、大きな効果が得られるところを体系的に探し、最適化を行ってください。

　コードが単純であれば、この探索は容易です。

　発展　〜プロトタイプで最適化

　まず動くプロトタイプを作ることは、最適化の観点からも効果的です。

　プロトタイプを使うと、「コードを書かなくて済む機能がわかる」という学習効果があります。コードを書かないことは、パフォーマンスを上げることに貢献します。書いていないコードは、最適化しなくても済むからです。

　「もっとも強力な最適化ツールは、削除キーである」「もっとも生産的な日は、1000行のコードを捨てた日だ」という、皮肉めいた格言もあるほどです。