コード最適化の個人的三原則

最近、アプリケーションのパフォーマンス・チューニングやコード最適化ついて、自分の考えを開陳する機会が何度かあった。

足し合わせて要約すると、以下のような感じになる。

◆コードを直す前後に計る
コード最適化に当たっては、修正を加えるに先立って、まず現時点の速度やその他のパフォーマンス指標を計測し、プロファイラ等を用いてボトルネックを突き止める。しかる後に、該当コードをピンポイントで修正し、それから再度パフォーマンスを計り直し、修正前と比べて効果を確認する（効果が無ければ元に戻す）。

…というのが、まあ、常識的な流れだが、実際の現場では意外とちゃんとできていない。

場当たり的な思いつきのパフォーマンス改善策を、システム全体のソースコードにバラまいて内部品質を下げてしまい、パフォーマンスチューニング改善作業そのものを停滞させてしまう場面がかなりよくある（これはまた、別の機会に詳述したい）。

カンに頼ったやみくもな対処は止めて、とにかく実測で把握する事がまずは必須。

◆数値目標を立てる
まあパフォーマンス向上というか、ほとんど何にでも一般的に当てはまる仕事の基本とも言える事だから、まあ、あまり説明がいらない気がする。

ところが、実際の現場では「とにかく速く」なんてお題目の下で作業が行われる事が結構多い。

こういうのは、要するに精神論・根性論みたいなものだから、そういったスローガンのもとでの作業は、無駄にプレッシャーが増加するだけで結局はあまりうまく行かない。

効果の薄い小手先の対応をせいぜいガンバッテみたりはするけど、具体的な目標を立てておけば決断できたはずの本来的な抜本対策が、なんとなく見過ごされたり、あるいは見てみぬふりをされたりする。（目標の立て方にもいろいろあるが、詳しく立ち入るのは別の機会にする。）

具体的な測定可能な目標を立てることが肝要。

◆最初から継続的に計る
これも「何事も早めに確認して早めに対応するのがよろしい」という、パフォーマンス話に限らず人の営みのほとんど全域に当てはまりそうなプラクティス。

まあ、リスク管理の基本中の基本でもあるはずなんだけど、なぜかシステム開発に限ってはなおざりにされている。かなり多くのプロジェクトで、パフォーマンスに関するテストや最適化を開発期間の一番最後にもってきて、関係者一同、毎度頭を抱えることになる。

開発初期から、継続的に計測する仕組みを作って監視するのが大切。

====
という３点について、自分としては、かなり当たり前の言わずもがなの事だと感じているが、いろんな反応があった。単なる同意だったり、なるほどと感心されたり、わかってはいるけどウチじゃ難しいんだよなって感じの苦笑いだったり。

まあ、各現場でそれぞれ文化や事情があるからなあ。