okkyの日記： Robust な戦略

アブラハム・リンカーンの言葉らしいのだが、本当の時間がわからない。

If I only had an hour to chop down a tree, I'd spend the first 45 minutes sharpening my axe.

45分バージョンの他に40分バージョンもあるらしいのだが…それはともかく。Robustな戦略最大のポイント、それは準備。別名ノー手戻り。エイリアスはデバッグサイクルを回すな。私に言わせれば、これに尽きると思う。

木を切り倒す必要があるなら、まず最初に斧を磨ぐべきなのだ。斧を磨いだ後ならば、木を切り倒す事ができる。しかし、斧を磨がなければ、金属バットで木を叩いているのと同じことだ。それで木を切り倒すのは、そりゃ骨だろう。

--

プログラミングだって同じだ。プログラムを書くためにいきなりキーボードの前に座るのなんて愚の骨頂だ。プログラムを書くためには、まず全体像を見通さなくちゃいけない。だからプログラムの全体像を図に描かなくてはいけない。プログラムの全体像を描くにはアルゴリズム等の基本知識が必要だ。だから図を描く前に最新のアルゴリズムをチェックしておかなくちゃいけないし、記憶しているものも参考資料のコピーを手元に取り直しておくべきだ。

となると、プログラムを書くために最初にやることは、図書館めぐりと、本屋めぐりだ。図書館がしっかりしていないソフトベンダーなんて当てにしてはいけないし、就職してもいけない。

また、いきなりプログラムを書き始めてはいけない。脳みそはあなたが思っている以上に粗雑なつくりになっている。まず脳みそがプログラムを作らせても安全なぐらい正気で論理的にモノを考えられる状態かどうかを確認しなくちゃいけない。ワインバーグの文章読本にも書いてあるが、コンピューターゲームとかでこの正気度を確認するのは、一つの手だ。全部のカードが表に向いているのに、明らかな誤手を打つような状態は正気とはとてもいえない。少なくとも、観察力が欠落している事は間違いないのだから。だからゲームをしている暇がないなんて奴のコードは当てにしちゃいけない。常にゲームが2，3個立ち上がっているようなスクリーンで書かれるコードこそ、最高品質なのだ。

条件が全部揃って描きあげたプログラムは、テストをしても引っかかるポイントが圧倒的に少ない。デバッグサイクルが 1/10 以下で済む、なんて場合さえある。一般にデバッグサイクルは1回回すたびに、コーディング費やした時間の 1/2 以上を消費すると言われている。もし、あなたが10kline当たり1つの間違いしか犯さない天才だったとして、事前調査に2コーディング時間を費やしたとしても、バグが4つ以上減るなら元は取れるのだ(40kline あれば十分だ)。

# し、多分そうやって作ったプログラムは、全体の
# 見通しなども良いだろう。

私の知る限り、私の周りで最短は 3行で 1bug。10行で30bugってのもあったな。大抵の人は準備に相当時間をかけても十分ペイする。

--

ひとつ上のプレゼン。という本によると、コピーライターなどのプレゼンにおいても、商品を買う人が何を求めているのか、商品を作る人は何を訴えているのか、の2点についてじっくり考えたプレゼンが勝つ、と言っている人は多い。これなども準備がいかに大事か、準備のために寸暇を惜しまない事で後にどれほど大きな時間を節約できるかの良い例だろう。

--

Optimal な戦略の場合は、on going で細かく修正するし、修正するだけのリソースを投入すると言う大前提がある。さらに、その手間が楽しいからこそ Optimal な戦略を用いるのだ。だから、実はここまで準備に気合を入れなくても大丈夫だ。つーか、入れると楽しさが減る(おぃっ)。

しかし、極力そいつのために時間を割きたくないからRobust な戦略を使うのだ。ならばこそ、最初に斧を磨ぐ必要がある。

まぁ、Optimal な戦略の場合、斧を磨く事をいちいち意識しなくても、判ってるってのもあるんですが。

--

えぇ、ここまではすごく筋が通ってるんですがね。問題が一つ。

私の趣味は本を読むことでしてね。参考資料を集めて資料を読み始めたら最後…ここに関しては Optimal 戦略が適用されてしまうんですよ。

嬉々として集めた膨大な資料、うきうきと読み続けてはいますが、一体いつになったら読み終わるんだろうかと言うのが…。

# ToDo ゲームが山になっているのと同じか… orz

人生山あり、オチあり。