今までに扱ったことの無い分野で新規開発をする場合、いろんな問題が出てくるだろう。そのようなときに、何をどうすればよいのか迷うことがあるだろう。そのようなときに、複数の課題があるときに、何をどの順序で解決していけばよいのか迷うこともあるだろう。
私が心がけているのは、「動くようにする、正しくする、速くする。」の順序で物事の優先順位をもって考えてようにしていることです。この内容は何かの本で読んだことからきている。何かしら動かないうちは、正しくすることもできないし、正しくなっていないうちは、速くすることに意味がない。
物事を解決する際に、全てのことが同時に解決することは少ない。
前に経験を積んだことのある分野の近くでは、動いて正解率もそれなりに高くて、メモリ消費や処理時間が少ないもの１回目の挑戦で作れることがあったりもするが、それは極めてまれなことだ。
1. 何かしら既存の技術をまねて、「動くようにする」のが最初だ。
2. 次に「正しくする」は、正解率を上げることかもしれないし、精度を向上させることの場合もあるだろう、ノイズや外乱の影響を受けにくく、ロバストにすることかもしれない。「正しくする」は、プログラムのバグをつぶすだけじゃない。そして、そのモジュールを使う中で適切であるのか、使われ方として正しくすることも必要だ。
3. そして最後に、「速くする」が来る。
「速くする」のは、いろんな方法がある。
- 高速なマシンを使う
- 予め計算済みの結果を持っておいて、それを利用する。
- 複数のコアを使って高速化する
- GPGPUを使う。
- 高速なマシンに処理を任せる。
- 画像の解像度を下げるなどしても性能の劣化がないことを確かめて使う。
- ボトルネックになっている部分のアルゴリズムを高速なアルゴリズムに置き換える。
場合によっては、速くしないという選択もあるだろう。
たくさんの課題があって何から手をつけていいのか分からない人、とりわけPMには、「動くようにする、正しくする、速くする。」の言葉を贈りたい。
付記：
「速くする」は、ソースコードを外部に開示できる場合には、外部の会社の力を借りて速くすることができる。「速くする」はソースコードが開示されていて、アルゴリズムがfixされていれば、それなりに速くする手はある。ソースコードをprofilleして、遅くなっているところを特定すれば、速くする方法はいくらでもある。for ループは OpenMPを使うことで速くすることができます。
しかし、「動くようにする」と｢正しくする」は自分たちで何とかする必要がある。動いていないコードを、「動くようにしてくれ」と外部に発注することはできません。
付記：
速くすることを優先して、正しくすることを後回しにしたときに生じることは、貴重な工数を無駄にしてしまうことになります。速くするために、縮小した画像を用いて処理時間を短縮することは容易に思いつくことです。しかし実装した後になって、精度的な理由で使い物にならないことが判明して使えなかったという経験をしたことがあります。
正しくするために作成した自動化テストは、無駄になることは少ないように思います。
付記：
ハードウェアで十分な計算資源を得て高速化するのが一番確実です。ハードウェアで高速化する場合には、アルゴリズムやソースコードが分かりにくくなることが防げます。また、アルゴリズムを簡潔なままにできるので、テストもしやすいものになります。
ハードウェアを貧弱なままに高速化しようとするときには、アルゴリズム上の工夫が必要になります。そのことによって処理の見通しが悪くなって、ソースコードの可読性が低下しやすくなります。そのことで、テストもいっそうの注意が必要になります。
付記：
どうやら、ケント・ベックの言葉のようです。
次の記事でも、「動くようにする、正しくする、速くする。」の順序であることを述べています。
GNUプロファイラーによるコード処理速度の向上